Support/SUMOdev Sprints

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 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

Additionally, 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.

A sprint is created in http://scrumbu.gs/ with the url for the Bugzilla query we use to denote the sprint.

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?
   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

Sprint status

At any point during the sprint, you can see the sprint status at: http://scrumbu.gs/projects/sumo/

Mid-sprint tweaking process

Things will come up that will require mid-sprint tweaking of the sprint.

When non-emergency bugs pop up, file a bug and at the next stand-up meeting bring it up. Options for dealing with this include:

1. pushing the bug off until the next sprint
2. adding the bug to this sprint with no other changes
3. adding the bug to this sprint and pushing another bug off to the next sprint
4. some fourth thing

We can figure things out as they come up.

When emergency bugs pop up, work on it and we can figure out what to do sprint-wise at the next stand-up.

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

• Scrumbu.gs: SUMO
  • http://scrumbu.gs/projects/sumo/
• BugzillaJS
  • amo: (https://addons.mozilla.org/en-US/firefox/addon/bugzillajs/)
  • github: (https://github.com/gkoberger/BugzillaJS) in case it has newer features
  • make sure to enable "Agile backlog" in the BugzillaJS preferences
• Planning Poker:
  • http://planningpoker.com/

Links are sent out before the sprint kick-off meetings.