Support/SUMOdev Sprints: Difference between revisions
(initial page for sumo planning poker) |
(added links, tweaked header) |
||
| Line 10: | Line 10: | ||
=== | === Sprint kick-off meetings === | ||
At the beginning of each sprint, we have a planning meeting. | At the beginning of each sprint, we have a planning meeting. | ||
| Line 65: | Line 65: | ||
After a research bug is finished, we can figure out what to do with the results using our tweaking process. | After a research bug is finished, we can figure out what to do with the results using our tweaking process. | ||
=== Useful links === | |||
* Luke's BugzillaJS: (https://github.com/groovecoder/BugzillaJS) Make sure to disable updates otherwise you'll get updated from Luke's fork to the actual BugzillaJS. | |||
* Planning Poker: (http://planningpoker.com/) Links are sent out before the sprint kick-off meetings. | |||
Revision as of 18:38, 10 January 2012
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:
- make SUMO development more predictable
- 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 s=2012.1 p=2
Tags are as follows:
- u= the group this affects?
- c= the component
- s= which sprint this is going in. e.g. 2012.1 is the first sprint of 2012
- p= the number of points estimated for this bug
During the planning meeting, we go through each bug and:
- figure out what the bug is about
- is the bug sufficiently fleshed out?
- yes - estimate how many points the bug should be worth and come to a consensus with that
- no - file a research bug for this sprint to flesh it out, figure out details and/or file new bugs
- 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
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:
- pushing the bug off until the next sprint
- adding the bug to this sprint with no other changes
- adding the bug to this sprint and pushing another bug off to the next sprint
- 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.
Useful links
- Luke's BugzillaJS: (https://github.com/groovecoder/BugzillaJS) Make sure to disable updates otherwise you'll get updated from Luke's fork to the actual BugzillaJS.
- Planning Poker: (http://planningpoker.com/) Links are sent out before the sprint kick-off meetings.