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


Work is visible in sprint backlog
Team velocity is less impacted

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


– 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


– 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


4 Responses to Managing Future Bugs (Known Unknowns) in the Sprint

  1. The con about work being hidden shouldn’t be the case because if a defect is added to the sprint it will (should) be visibly added to the sprint backlog.

    Using and estimating placeholder stories to estimate the unknown is a very bad idea. Velocity is best used for release planning, not sprint planning. If you point work that was unplanned and include it in your velocity, your velocity will be inflated relative to the known work for the release that you need to burn down. This will cause you to overcommit for your next release.

    • Davide Noaro says:

      Hi Andrew thank you for your comment.

      About your first remark the fact that is “hidden” is because I’m taking about bugs that you know they will arrive but you don’t know them in advance (known unknowns) and normally you cannot add something to a Sprint backlog once the Sprint is started. It’s different to have a list of bugs known in advance and choose some of them to be fixed in the Sprint. Here we keep a bandwitdh to eventaually fix production bugs that can occurs (you don’t know if they will come and you don’t know them). Sure at the end of the Sprint you can always say: “We committed on A, B, C… but finally we did also Bug 1, 2 and 3 that came afterwards”. An option is to create a placeholder story without estimating it just to give visibility that the team is working on possible incoming bugs. This is normally what we did when I worked in a Scrum team: this gives the visibility without estimating in story points.

      About estimating placeholder stories, It’s not to point work that is unplanned and include it in the velocity. It’s to plan and commit work in the sprint (the knowns unknowns) giving it a relative estimation in points so that there are less fluctuations in velocity for release planning.

      I understand that it’s a bad idea, but for me not because velocity is best used for release planning (more you have fluctuations in velocity and worse is for your release planning I think) but because it’s difficult to associate story points with days (unless you have enough historical data) so most probably you will end with a wrong relative estimation.

      • I average velocity over many sprints, such as a whole release or even two depending on how long the release is, so I don’t have much trouble with unstable velocity. I also go to great lengths to have a stable velocity, i.e. by having stable teams, by using TDD, and by having very high quality. We’ll plan for a conservative velocity and manage what we do to maintain that.

        This is a hard thing to argue over because there is so much context that matters when deciding which approach to use. Context and also preferences such as balancing adaptability versus predictability, batch size, and such.

  2. Davide Noaro says:

    Adding here the article written by Andrew Fuqua about estimating placeholder stories that can help to have a complementary point of view on the topic:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: