Support/SUMOdev Sprints

From MozillaWiki
Jump to navigation Jump to search

We're experimenting with a two-week sprint where at the beginning of the sprint we have a planning meeting.


Goals

The goals of this process are two fold:

  1. make SUMO development more predictable
  2. create a bunch of data that shows our velocity and makes our estimates better


Sprint kick-off meetings

At the beginning of each sprint, we have a planning meeting.


Before the meeting: Prep

Before the planning meeting, people suggest bugs that should go into the sprint. These bugs are tagged with something like this in the whiteboard: 

   u=user c=search p=2

Tags are as follows:

  • u= the primary group of users the bug benefits (user|contributor|sumo-team|dev)
  • c= the component
  • p= the number of points estimated for this bug

We use the bug's target milestone to denote which sprint the bug is in. e.g. If the milestone is 2012.6, then it's in the "2012.6" sprint.

We use the bug's priority to denote the priority of the bug in the sprint:

  • P1 - MUST get done as soon as humanly possible
  • P2 - MUST get done this sprint
  • P3 - SHOULD get done this sprint
  • P4 - COULD get done this sprint if we have time
  • P5 - Think about possibly getting it done this sprint if we have time and we're bored.

A sprint is created in Scrumbugz with the url for the Bugzilla query we use to denote the sprint. Sprints are created by someone with admin privileges and the magic toothbrush.

You can see a list of all of the SUMO sprints and dates at http://scrumbu.gs/projects/sumo/.

Before the meeting, go through all the bugs in the sprint and help to flesh out any that need fleshing out.


During the meeting

During the planning meeting, we go through each bug and:

  1. figure out what the bug is about
  2. is the bug sufficiently fleshed out without outstanding issues?
    1. yes - estimate how many points the bug should be worth and come to a consensus with that
    2. no - file a research bug for this sprint to flesh it out, figure out details and/or file new bugs
    3. if we stare blankly for longer than a few seconds, then we should file a research bug for this sprint and move on

If we end up with more points than we want for the sprint, we figure out which bugs to push off to another sprint.

Points:

  • 1 - 1/2 day
  • 2 - 1 to 2 days
  • 3 - 3 to 4 days

If we think the bug will take less than 15 minutes total time, then just do it--don't put it in a sprint.

Sprint status

At any point during the sprint, you can see the sprint status at the sprint status page. You can find that page for any given sprint at http://scrumbu.gs/projects/sumo/.


Mid-sprint tweaking process

Previously we would add and remove bugs during meetings or upon consensus. That is no longer true.

Now we add bugs to the sprint on Kadir's approval unless it's an emergency bug in which case it's at the discretion of the developer. We don't remove any bugs from the sprint until after the sprint is over.

New bug types

In addition to bugs that result in code changes and get marked as FIXED when the code changes are done, we have these new bug types:

research
A research bug involves researching some question/issue. The end result could be to research the question/issue and file new bugs, document how something should be built or anything along those lines.

After a research bug is finished, we can figure out what to do with the results using our tweaking process.


When do things land?

We're doing continuous integration now. So we push code to production as soon as it's ready to go.

The target milestone on the bug tells you which sprint it was pushed to production in.

The code comments should tell you roughly when it was pushed to production.


Useful links

Links that used to be useful:

Retrieved from "https://wiki.allizom.org/index.php?title=Support/SUMOdev_Sprints&oldid=480403"