This is a guide on how to function as the scrum master.

Sprint Pre-planning

Create the sprint page

Scrum Page Creator

Target Velocity

• Fill in the scrum page creator with the following:
  • Sprint name: vXXX-SY
    • e.g. v2.1-S9
  • Milestone name: XXX SY (DDMMM)
    • e.g. 2.1 S9 (21Nov)
  • Velocity: This field is unimportant, but you should probably enter the target velocity.
  • Bug number: Leave this empty. The SMS team uses this.
• Click on the "Dialer" link or click here and copy-and-paste the contents of this page into the "Paste a template here" section.
• Create a wiki page of the form FirefoxOS/Comms/Dialer/Sprint/vXXX-SY.
• Copy-and-paste the output of the scrum page creator into this new wiki page.
• Edit the current sprint page to point to the new sprint page.

Fill in the dates

The generator doesn't fill in exact dates, so you will have to do this yourself.

Set up retrospective Etherpad

Retrospective Etherpad

bold & underline

bold

bold

bold

vXXX-YY

Things we did well

Things we could do better

Action items

Select bugs to work on

Since the other participants don't have a clear picture of everything that the team is currently working on, the responsibility falls mostly on you to decide what we will work on. Having said that, you should ask if anyone would like to include more bugs or exclude any that you included, and discuss from there.

It is recommended that you take more bugs than you expect to need, as you can always cut them out of the sprint during sprint planning.

Including bugs in a sprint

• Set the Milestone to this sprint.
• Add a variation of planned-sprint to the Whiteboard:
  • If an estimate is required: [planned-sprint c=]
    • An estimate is required if this bug hasn't previously been estimated, and you have any uncertainty what-so-ever about the complexity of it. You should never go ahead and do an estimate on your own unless you are absolutely certain that it should get a complexity of 1.
  • If you're rolling forward a bug from a previous sprint: [planned-sprint c=X][in-sprint=vXXX-SY]
    • e.g. [planned-sprint c=3][in-sprint=v2.1-S8] for a bug that is being rolled over to v2.1-S9 and was previously estimated at cost 3.

Priority for bugs

1. Blockers that are unassigned and/or have no milestone.
2. Roll forward incomplete bugs from the previous sprint.
   1. Note: Don't roll forward a bug if you suspect that it can still be completed in the previous sprint.
3. Partner requests that aren't blockers.
4. Features, if in a feature cycle.
5. Requests from other teams.
6. Tech debt fixes and nice-to-haves, left to your discretion.

Set up estimates Etherpad

Estimates Etherpad

Estimates List Generator

Once you have decided on the bugs for the coming sprint:

1. Open the Estimates List Generator.
2. Fill in the list of team members.
3. Select the correct milestone.
4. Copy and paste everything below -------------- COPY ALL BELOW -------------- into the Estimates Etherpad.

Sprint Planning

Agenda

1. Standup
   1. See #Hosting the Standup
   2. Over Vidyo since we're already on it.
   3. Ask people to fill in retrospective items (see below) while waiting for everyone to show up.
2. Retrospective
   1. Process
   2. Etherpad
3. Go over incomplete bugs, find out why we didn't make it
4. Go over previous estimates, see how accurate they were
5. Sprint planning

Sprint Planning Process

Process Explanation

Estimates Etherpad

Current Sprint

All Available Bugs, Blockers, etc.

Velocity Calculator

1. Follow the Process Explanation.
2. Guide the conversation, ask for opinions from the experts of bugs.
3. Once you have enough information, ask for people to enter their estimate into the Estimates Etherpad.
4. Make sure that everyone provides an estimate.
5. Only accept 1, 3, 6 as estimates. If people give 6+, the bug should probably be broken up more.
6. Write the consensus in the Consensus section. If there is a split, then take the larger number.
7. Once all of the estimates are collected, update each of the bugs with the consensus numbers. That is, switch the whiteboard tags from [planned-sprint c=] to [planned-sprint c=X], where X is the consensus number for that bug.
8. Refresh the Velocity Calculator. Aim for the target velocity. If the current total is larger than the target, cut bugs until it's within the target.
   1. The target velocity depends on the type of the current cycle, i.e. feature or stabilization. During feature cycles, you will want to really load up on points up-front. During stabilization sprints, you can expect lots of incoming bugs and blockers mid-cycle, so you will want to keep the up-front point total lower. See the estimates explanation for more info.
9. Assign bugs, asking for volunteers. If nobody volunteers, look for whoever has the lowest point total assigned to them, and give the bug to them, as long as they're not extremely misplaced working on it.

Sprint Post-Planning

Copy PTO over to Sprint Page

Estimates Etherpad

Current Sprint PTO Section

Copy the PTO section from the estimates Etherpad over to the PTO section on the sprint wiki page.

Copy retrospective notes to Sprint Page

Retrospective Etherpad

Retrospective Explanation

Copy the retrospective notes from the retrospective Etherpad over to the Retrospective section on the sprint wiki page.

Adjust point totals

Estimates List Generator

Make sure that all bugs have their point totals up to date. You should have mostly done this already, but may have missed a few. Double check the Estimates List Generator to make sure that it's empty for this sprint.

Do the post-standup

Make sure not to forget the post-standup. See #Hosting the Standup.

Hosting the Standup

• Current hosts: drs, gtorodelvalle, thills
• Hosts rotate every week.

1. If you're not available for a standup that you're scheduled to host, then ask for someone else to host instead for just that time.
2. Start by pinging everyone who should be participating.
3. List any administrative items you have, and then ask for more from other people (look at the Etherpad).
4. Look at the list of blockers and blocker nominations and see if there's anything new or that needs action. Mention these during this time.
5. Move to individual updates. Go alphabetically, in descending order.
6. If someone's update is taking longer than 3-4 minutes, you should generally cut them off and ask them to talk about it after the standup.
7. Copy the reports from the GDoc to the wiki page for that day. Use the Etherpad-to-Wiki converter to format it. You can just copy and paste the whole thing and the converter will do everything for you.
8. Ask the person who should be hosting the week after you if they'll be available. If not, move onto the next person.