Skip to main content

Unexpected items during sprints

Last post 01:23 pm August 14, 2019 by Ruchira Parchur
16 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.

02:17 pm August 11, 2018

Hi Ian,

I am continuously following your blogs and it is really helpful to get through all those scenarios we face while applying scrum.

I have one question: how we calculate sprint velocity of a sprint if any unplanned request comes in between sprint which is of utmost priority and we need to deliver it asap else it would lead to heavy loss to the customer on daily basis? It is 2 weeks of sprint duration in which team estimated 21 story points and all work is completed except last one of 5 story pointer in which is in progress. In this situation team has no choice and has to start working on unplanned request. 

Thanks for any clarification.

02:52 pm August 13, 2018

No change in calculation, you end with 16 story points for that sprint. You should remember about the reason why it was lower than usual during next retro and planning, and that's it.

03:33 pm August 13, 2018

Does that fast-tracked work add value to the product? Is it a Product Backlog Item which the Product Owner recently discovered, and which the Development Team agreed to action immediately instead of refining and planning it into a future Sprint?


04:02 pm August 13, 2018

Why not switch to Kanban and see how the team responds to the change requests/requirement churns from the Product owner?

05:11 pm August 13, 2018

In my opinion, as an exception to existing process/practices, unplanned work deemed critical by the PO may be presented to the Development Team for inclusion in the current sprint, provided the new item does not jeopardize the Sprint Goal and the Development Team is able to forecast completion of the item within the sprint.

it should be noted that there is increased risk associated with an unplanned item, and the Development Team may need to adjust their forecast to accommodate the new item.

From a Story Point/Velocity perspective, it is important to keep in mind that these items support planning, and therefore since unplanned work is not part of the "planning" process, I would propose relieving the Development Team from having to relatively estimate such items.   

They should still judge (gut feel) whether their forecast needs to be modified due to the new item, though.

09:54 am August 14, 2018

I have once taken 2 members of the development team out of the development team and made them dedicated for maintenance. This way there was capacity to tackle incidents while the actual development team was not disturbed during the sprint. The members of this "maintenance team" cycled every sprint. When the maintenance team had idle time they tended to assist the development team with little things, even getting coffee for everyone.

11:38 am August 14, 2018

I have once taken 2 members of the development team out of the development team and made them dedicated for maintenance.

Out of curiosity: What was your role on that team?

04:33 pm August 14, 2018

I have once taken 2 members of the development team out of the development team and made them dedicated for maintenance.

I like the idea of rotating 2 members as opposed to one. since that approach protects against a single point of failure, and promotes KT and cross-training.

To add to Julian's question, how large was the Development Team?



12:23 pm August 13, 2019

To All Experts here, need help!


When business demands of some random tasks to be done for customers, which the Scrum Team is not aware of but one developer is, and the work gets directly fed into developer's list of tasks without involving the Scrum Team and the Scrum process. 

What would be the best possible approach that you as a Scrum Master would undertake to resolve such issue in future?

01:06 pm August 13, 2019

Why does the developer have a list of tasks to feed stuff into? Isn't there a Sprint Backlog which is owned by the whole Development Team?

Why doesn't the Product Owner order this new work on the Product Backlog...and what does he or she think about this mechanism being subverted?

Why does the developer accept this work in the first place, when he or she ought to be concentrating on the team plan for meeting the agreed and committed Sprint Goal?

03:21 pm August 13, 2019

As a Scrum Master I would get the Developer and Product Owner together and discuss all of the questions that @Ian Mitchell asked.  Coach them to arrive at the "right" answers to those questions.  SPOILER: the "right" answer is the Developer should be directing the people making these requests to the PO. 

12:04 pm August 14, 2019

Thanks @Ian and @Daniel for your suggestions.

There is a Sprint backlog but simultaneously there are some technical requirements which have been directly going to the developers (which ideally shouldn't happen).

I have noted your suggestions to begin with, the people mindset needs a change/coaching.

Thanks much for these valuable thoughts.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.