Managing Future Bugs (Known Unknowns) in the Sprint

This article has been firstly published on the Scrum Alliance site.

As ScrumMaster, there are different situations we have to deal with. Here I’d like to address the following topic: how to deal with future bugs that can arrive at highest-level priority during the sprint (in other words, we must treat them).

This is a common situation if the Scrum team is not only responsible for developing new functionalities but also for solving bugs found in the production environment, linked to user stories or not. In companies that haven’t fully moved to Agile, where Scrum can have a Waterfall-at-end interaction, these bugs can be opened during the quality assurance phase (after the Scrum process) — but we don’t know how many there are.

When bugs are already known, they can be put in the product backlog during the sprint planning; they can be estimated and considered user stories. Sometimes, however, all we know after the sprint is started is that we will have some bugs to treat during the sprint. These future bugs can arrive later, with a high priority compared to the user stories in the sprint. It’s an example of the more general problem of how to manage the “known unknowns” in a project. We know that we will potentially have some bugs to treat, but we don’t know how many or what they are.

We have to plan the sprint content, and we have to deal with these “known unknowns” bugs. How can we estimate the bugs in the sprint? How will these bugs affect the team sprint velocity?

Future bugs estimation: Story points versus capacity days

The first option could be to replace the bugs (not present at the time the sprint starts) by so-called “placeholder stories.” Estimating such stories can be difficult because we don’t know their complexity. The range can be from a reassignment of the bug to another functional team (if it was wrongly assigned to the Scrum team) to a complex fix done by the Scrum team itself. We could assume that these “placeholder stories” are of a small to medium size, adding some of them into the sprint.

An alternative approach is to have just one “placeholder story” for all the bugs, with a percentage of the sprint velocity associated with it.

The main point for the first option is that the “known unknowns” are managed, estimated in story points; and these story points are considered in the sprint commitment. In this case the velocity of the team will be not impacted by this “extra” work, because the work is visible and estimated in story points.

The second option could be to leave a buffer in the number of days in the sprint needed to treat these bugs. The time reserved to manage the “known unknowns” could be considered as less capacity for the team during the sprint. This brings a lower commitment in story points (just as when team members take vacations during the sprint). This option affects the team velocity because some capacity is reserved to do “extra” work in the sprint that is not visible and that hasn’t been estimated in story points. As ScrumMaster, you’ll have to pay attention to keep track of the team velocity in association with team capacity (available working days in the sprint), because in this case the velocity can have more fluctuations.

Summary for managing future bugs (known unknowns) in the sprint

ESTIMATION OF PLACEHOLDER STORIES

Pros:
– Work is visible in sprint backlog
– Team velocity is less impacted

Cons:
– Estimation in points for something unknown is difficult and easilly wrong

USE CAPACITY DAYS

Pros:
– Easier if we know that some days must be reserved for this (for example, associated to another budget line)
– Keep estimation for real features that can be easilly estimated relative to others

Cons: 
– Work is hidden in the sprint (bug fixing considered as “vacations,” no story points or user stories associated)
– Could bring to more fluctuations in team velocity