Support/SUMOdev Sprints

From MozillaWiki
Jump to: navigation, 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 s=2013.15

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
  • s= the sprint the bug is assigned to, such as "2013.16"

Sprint numbering is the year the sprint occurred it, followed by the number of the sprint. The first sprint in 2013 is 2013.1, the second is 2013.2, etc.

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:

  1. go through all the bugs in the sprint and help to flesh out any that need fleshing out
  2. assign points to any bugs where the estimations are easy to do, obvious and or have already been done but just need to be codified
  3. mark any bugs with "[needsverify]" in the whiteboard field that require a business person to verify the work on our stage environment
  4. mark any bugs with "[needsflag]" in the whiteboard field that require a flag

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
  3. does the bug require the work to be done behind a flag?
    1. yes - add an additional point and make sure it's noted in the whiteboard
  4. does the bug require verification from a business person afterwards?
    1. yes - make sure it's noted in the whiteboard

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

If too many bugs require verification, then we might need to bump a few to the next 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.


Bug flags we use

Bug flags are specified in the whiteboard field at the end.

needsverify 
Bugs flagged with this require verification from a business person while on Stage before they get to production.
needsflag 
Bugs flagged with this require being implemented behind a flag so that we can switch back and forth while in production.


New bug types

The bug type is specified in the title of the bug at the beginning.

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 we can.

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.

If the bug was marked as "needsverify", then the changes are pushed to stage where they wait for a business person to verify them. If it takes longer than a day, we should chase down the person and if we can't contact them, escalate to Kadir or Ibai.

Useful links

Links that used to be useful:

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