We are in the middle of a Sprint, and a critical bug was found in production. It will take two developers three days to fix. How do we account for this in Scrum? Do we swap out a story of equal size, or do we just accept that the Sprint Goal might not be met?
3 answers
First, verify if it’s truly "critical." If it is, the team must address it immediately. In Scrum, the Sprint Goal is the commitment, not the list of tickets. If the bug fix prevents the team from reaching the Sprint Goal, the Scrum Master must inform the Product Owner immediately. Usually, we negotiate to remove lower-priority items from the current Sprint to make room. A long-term strategy is to reserve 10-15% of your team's capacity as a "buffer" for unplanned work. This prevents the Sprint from collapsing every time a bug appears, allowing you to maintain a predictable velocity for the planned items.
Deborah, isn't a "capacity buffer" just an invitation for the team to work slower? If we tell them they only have to work at 85% capacity, won't they just fill the time? How do you ensure the buffer is actually used for bugs and not just hidden slack?
We use a "Bug Shield" role. One developer is rotated each sprint to handle all incoming small bugs and support issues, while the rest of the team stays focused on the Sprint Goal.
The "Shield" or "Batman" role is great, Sandra. It protects the flow of the rest of the team and gives everyone a chance to learn the maintenance side of the codebase.
Justin, it’s about transparency. The buffer isn't "free time"; it's a risk management tool. If no bugs appear, the team pulls in items from the top of the Product Backlog. This keeps the momentum going. The goal isn't to be 100% busy; it's to be 100% effective at delivering value. Busy-ness and productivity are not the same thing in a complex software environment.