Managing Future Bugs (Known Unknowns) in the Sprint

15 January 2013

Davide Noaro
Amadeus

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), which in this case can vary more.

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 of unknown difficulty

CAPACITY DAYS

Pros:

  • Easier if we know that some days must be reserved for this (for example, associated to another budget line)

Cons:

  • Work is hidden in the sprint (bug fixing considered as "vacations," no story points or user stories associated)
  • More fluctuations in team velocity

Article Rating

Current rating: 0 (0 ratings)

Comments

Sergey Kotlov, CSM,CSPO, 1/15/2013 2:34:13 AM
I saw both approaches in use and I personally prefer the second one. I found out that team members tend to overestimate bugs which appear during the sprint.

After several attempts the team I worked with decided to have a capacity interval because they agreed on overestimation.

Capacity days method works very well if you don't have too many bugs and the amount of additional work is quite small comparing to the sprint's one.
Yan Borowski Machado, CSM,CSD, 1/15/2013 10:15:41 AM
Here in my team we do what you do. We have a card named "Routine" with some points that don't mess our Sprint Goal. We add also some other stories that don't belong to our Sprint Goal (same count of "Routine" card's points), but will be good to be done. When our PO bring a bug to our team we estimate this bug and discount the estimated points to the bug from "Routine" card. We do this because our team works with 75 percent of effort during the sprint. Then stop to estimate some bugs will not being interfering on our sprint goal. If the PO accepts our estimate we put the bug to our to do list. I know.. Someone will talk that our sprint need to be Canceled and a new sprint should be started.. but it works fine for us.
Davide Noaro, CSP,CSM,CSPO, 1/20/2013 10:07:39 AM
Thanks for your return of experience. Actually we are using the second approach with days removed from capacity and I find useful to take the velocity considering the capacity too (velocity / days) especially during the first sprints where there can be more fluctuations on just the team velocity.
Sudesh Singh, CSM, 4/12/2014 8:02:37 AM
Please clarify my query: In my company they are taking Enhancements in Sprints and they are not considering the product defects, it means the product defect doesn't have user story they are treated as normal approach of having FRD.

You must Login or Signup to comment.