Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
add comment

4 Answers

If this is critical, you must handle it.

To measure its impact on the sprint, you must log it.

Look at this information radiator:

alt text

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.

share|improve this answer
2  
+1 for must, as if there was any alternative –  user281377 Nov 25 '10 at 13:33
1  
Ok, so it's been added to the current sprint — but now what? This critical issue will get picked up and worked on at some point within the next two weeks and get delivered as part of the next release? –  Christopher Jan 12 '11 at 9:38
1  
@Christopher: ask your product owner what to do. Depending on how critical it is, you can wait until the end of the sprint or release an hot fix. –  user2567 Jan 12 '11 at 9:44
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.