Unexpected items during sprints

Last post 12:07 pm February 17, 2014
by Charles Bradley
4 replies
07:22 am February 14, 2014


My team has the following problem when running Scrum. We have sprints with a 2 weeks length and we establish a Sprint backlog during the planning meeting for each sprint. The problem is that a relatively large number of unexpected high priority items like customer issues are appearing and our product owner wants that these issues to be addressed immediately in the current sprint. Which is the best way to accommodate these unexpected issues in the sprint backlog?

We considered two options:
1. Reserve a predefined amount of resources like 20% for these unexpected issues.
2. To add the unexpected items into the sprint backlog as they are appearing and to remove other lesser priority items with an equivalent size.

What is Scrum recommending in this case?



08:33 am February 14, 2014

Hi Mircea

Reserving a certain percentage of a Sprint is a gamble because, by definition, the demand for unplanned work is indeterminate. If you have a service level agreement with the Product Owner to reserve 20% for this purpose then I dare say it can be made to work, although you'll have to think about how to make it transparent.

A better option is for the PO and the Development Team to trade items in and out of sprint scope when waste (unplanned work) arises. The MoSCoWing (Must/Should/Could/Won't) of requirements can help here. If you can initially agree that no more than half of the requirements (as measured by story points for example) inducted into a sprint will be Musts, this gives you at least 50% contingency for such trading purposes. The Coulds, and if necessary the Shoulds, may be traded out. It's still a gamble of course, but "up to 50%" is better contingency than 20%. Obviously if less than 50% unplanned work actually does arise during the sprint, then the Should and Could have requirements may be progressed as per the Sprint Plan.

Whatever percentage you agree on for Must-Haves, it's important to make sure that the stated Sprint Goal depends on these associated mandatory requirements, and not on any Shoulds or Coulds. Failure to do this might result in the sprint being terminated by the PO on the grounds that the goal can no longer be met. In other words the Sprint Goal should be clearly aligned to the Minimum Viable Product for the planned increment of that sprint.

You are fortunate that it is your Product Owner who wants these issues to be addressed immediately. Often it's a third party, which can make things rather more awkward.

07:58 pm February 14, 2014
08:44 am February 17, 2014

Thanks a lot!

12:07 pm February 17, 2014


As a Scrum Coach, I get asked this question all the time, so I created a chart to help people answer the question.