|
The question of managing bugs in production has been a large feature in my mind of late. Sprint's are not meant to have any items added into them, but for critical bugs, this is simply unavoidable. How does one go about managing this break in the sprint? Do you simply give a sprint a percentage "allowance" of time, thus only filling say 80% of the schedule with sprint items "just in case"? Thanks, Kyle |
|||
|
|
|
If this is critical, you must handle it. To measure its impact on the sprint, you must log it. Look at this information radiator:
There is a part called "Unplanned items". Put your critical bug there. As you see there is the inverse with "Next" part where you put more user stories than planned in case you complete the sprint faster. You will talk about it in the sprint review and/or the retrospective. The objective is to find how to limit them, and also adjust your velocity accordingly. |
|||||||||||||
|
|
If you use velocity as an 'allowance' indicator based on yesterday's weather, it will automatically adjust for some average amount of extra work cutting into sprints. If the production issue is caused by bugs created in earlier sprints it's OK to have the fixing work cut into the velocity of the current sprint. This way the team's velocity is 'compensated' for the points they shouldn't have earned previously. Sometimes you don't make all your sprint goals, get over it ;-) Velocity will average out to a lower number if it happens a lot. Any other non-critical stuff can just be included on the backlog for normal inclusion in a sprint. I prefer giving top priority to bugs and to not have them count towards velocity. All the time needed for fixing and troubleshooting production issues is automatically factored into the team's velocity. Only takes time to average out, doesn't really need a separate allowance. |
|||
|
|
|
I work in a team that does mostly development work, but is also responsible for existing complex systems. We've had this problem as well. Basically, we estimate our points based on the last sprint(s) and then reserve a number of points for the expected maintenance work. Should a maintenance task occur that exceeds this significantly, like a major outage, we add it as a user story and remove an existing one that has not started yet, to keep the sprint of the same size. If a major issue pops up that is less urgent, we move it into the next sprint. Yes, this is technically not following scrum. But the flexibility has worked well for us. We have refined this reserved time by asking the team at every planning meeting whether they see reason to deviate from the standard reservation. We introduced this after doing an office move which took us much more time than we anticipated, leading to many stories not being finished. However, do not just stick to how my team or any other team does it. Pick something, and just do it. There is no way to ensure that it will work well for your team. Try, and evaluate in the retrospective. If the team is unhappy, try something different and evaluate again. All teams are different, and their needs and limitations are different as well. |
|||
|
|
|
If it is a critical production issue, then you should be able to handle it directly, the chosen development methodology is irrelevant. A hotfix is not related to a regular release cycle (spints or otherwise). I'd suggest fixing it in a 'fix' branche, based on the code that's currently in production. |
|||
|
|
