Sprints work pretty well, but they can get messy when contributors start being involved, or when bugs overflow the time boundaries of a sprint (ie a bug was started near the end of a sprint, and isn't finished at the end of the sprint). Sometimes sprints can feel like "mini waterfalls". On the other hand, sprints have the advantage of letting PMs easily define what work should be done, and helping this information flow from PMs to developers. They also help timebox projects, so that we can say "this will be done during this two week cycle. This predictability is important. Surprised estimations are teh suck. It isn't fair to ask a developer to make an estimate on something that they haven't worked on before without time to do some research.
Goals:
- Reduce dependency on a fixed two week cycle.
- Maintain a level of predictability, within the error margins of estimation.
- Keep the amount of metawork to a minimum.
- Reduce the amount of "surprise estimations".
The basic unit is the bug. A bug can be in one of several states. This is inspired by the way I understand kanban, but I don't really know if it is the true kanban or not. You could imagine each bug as a card, and the cards progress from left to right as we work on them. In general, I tried to envision a more asynchronous version of our current sprints, and how that could be organized.
When a bug is first filed, or while it is still being designed, a bug is in this state. If it is unclear what the feature is, it should not move beyond this state until the problem and solution are better defined.
A bug becomes ready after it is assigned a priority and a work estimate (points). A developer should set the work estimate, and the work estimate should not be directly correlated to time, but an estimate of the amount of work on a point scale (suggested: 1-3 points).
A bug becomes selected when the project manager indicates that this is a bug that should be implemented "soon". This is equivalent to assigning it to a sprint, but is not tied to a two week cycle (or any other fixed time). There is a limit of the number of points that can be in the Selected queue at any time (guess: 8 * Developers, assuming 3 pt scale). The goal here is to provide a pool of things to work on that is larger than one bug per developer, but that does not grow to an unmanageable amount of work. If the PM decides something is more important, he can remove something from Selected, back to Ready, and replace it with a higher priority bug.
When a developer begins working on a bug, it enter the WIP status. These bugs should only come from the "Selected" pool. There is a limit on the number of points that can be in the WIP state. The goal is that each developer has enough work to always keep pushing forward; if something gets blocked, they can switch to another task in the WIP state. Something like 4pts * # of Developers might be a good starting point, assuming a 3 point scale for bugs.
When a bug is done being developed, it goes to review. The bug does not go back and forth between WIP and Review, it stays in review until it gets r+ed.
After the bug is reviewed, it is ready to deploy.
After the bug is on production, it is done, RESOFIXED.
A newly filed bug is New. Once metadata has been added to the bug, it is Ready. This metadata includes points and priority. Later the bug will be Selected: ie, the project manager indicates it should be worked on.
Other states could be added for things like UX design work, waiting for verification, or waiting for statistical analysis (like for search stuff).
Meta work is here defined as work about work, such as setting whiteboard flags, changing the bugzilla status of bugs, and manually moving bugs between states. Not all metawork can be eliminated, but it is desirable to minimize it. To this extent, many of the state changes.
A bug that is create is automatically assigned the "new" state.
Bugs are automatically set to Ready when a priority is set and a p= flag is set in the whiteboard field.
White board field?
Options:
- Bugs are changed to WIP when they are assigned to a developer (don't assign until you are about to work on it).
- Bugs are changed to WIP when a pull request is filed (file an empty pull request early).
- A whiteboard field.
When a pull request is filed, or, if option 2 is chosen above, when the pull request gets a comment that contains r?.
When the pull request is closed. This may have to check for r+ in the history of the bug, or a lack of a r-.
When the bug is marked as Resolved in Bugzilla.