In the sprint can we remove (move to the upcoming sprint) the planned stories (mid sprint), if we are 100% sure we can’t complete them?

Example given:

  • Suppose we planned to 5 stories to be completed in an sprint.
  • Midway the sprint we are sure one story can't be completed because of dependencies (or other reason).
  • Now can we remove this story so that, we have only 4 stories in the current sprint (and a cleaner burndown)?

I think we can’t do that, but have doubt.

The idea is that if we remove the user stories (which can’t be completed), we would have cleaner burndown chart.

What is the right way to approach this problem?

  • 3
    As a general rules, if you are doing stuff just to make your graph neater, its probably a bad idea.
    – Ewan
    Commented May 5, 2015 at 14:32

5 Answers 5


From the Scrum Guide:

During the Sprint:

  1. No changes are made that would endanger the Sprint Goal;
  2. Quality goals do not decrease; and,
  3. Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

The changes you mention fall into the last category, unless they endanger reaching the sprint goal. If the last story you're proposing to drop is the least important, chances are lower that it endangers the sprint goal.

If this happens frequently, spend a retrospective or two to find out how you could prevent this. Are you taking on too much work at the start of the sprint to begin with? Is the team in need of training? Was there too much stuff unclear when the work started? (be careful to not start doing full waterfall analysis though!).

Your burndown will now reflect the new situation and should now show that you're again on track for timely delivery of the new scope. Remember that the Burndown is a practice the team can use to see if they're still on track to deliver what they forecasted. If they do a new forecast (i.e. renegotiate scope), then the burndown will reflect the new status. If the Burn down is used for other purposes than the team's internal progress tracking, then the sudden drop may need to be explained. As Scrum trainers, we generally caution against sharing the burndown as an official report at the end of the sprint. That's not its purpose and can lead to people making incorrect assumptions.

You mention a Sprint Review Report. This is not an official scrum artefact, so I can't tell an official story about how it should be influenced. It sounds like a report from the Product owner to the stakeholders. If the Product owner previously communicated the forecast by the team, then it may explain that certain features were not delivered. But during the Sprint Review meeting you'd indeed show that all you've delivered is green (Done according to the DoD). What will also be visible is that your velocity will be lower than usual, which may trigger some questions.

The Scrum master should ensure that the development team looks at the underlying cause that caused this change to happen. The natural point in time to do so is at the Retrospective. Be wary that the team simply reduces its forecast or creates a long list they may call a "definition of ready". It's better when the team tries to apply automation to reduce overhead of testing and deployment and when the team has more frequent communications about the real intent of the PBI so that they better understand it.

  • Thanks, but I was thinking that it should not be allowed altogether (to drop a story midsprint). Now suppose we do it, what would be the impact on a) burndown b)Sprint Review report - we would be showcasing a reduced planned velocity, which we are able to achieve and all would look green? Commented May 5, 2015 at 9:32
  • 1
    @LalitSinghRana, if the story is dropped, then the burndown will show you finishing early. The sprint review should then cover this and the reason why (a story had to be dropped). The retrospective should then examine the reasons why the story had to dropped and how to avoid scheduling a story too early in future.
    – David Arno
    Commented May 5, 2015 at 10:33

The Sprint backlog is a forecast, not a commitment

In the 2011 revision of the Scrum Guide Jeff Sutherland and Ken Schwaber made an important change. They changed the word "commitment" to "forecast" in regard to the Sprint backlog.

The term commitment has two bad consequences:

  1. The stakeholders expect to have every single item delivered at the end of the Sprint, at any price. And, what is even worse, they begin making plans, assumptions and decisions based on this not yet confirmed fact.
  2. The development team focuses on delivering every single item of functionality which was promised at the beginning of the Sprint at any price... even at the expense of software quality or the real business value being delivered.

Now can we remove this story so that, we have only 4 stories in the current sprint (and a cleaner burndown)?

Whatever you forecast at the time of Sprint Planning is the baseline. You do want to show that one story is not completed. If you manipulate the baseline you will be sweeping the problems under the carpet and the team will miss an opportunity to learn from it.

What is the right way to approach this problem?

Again quoting from the Scrum Guide, "If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner."

You said that midway through the sprint you decided one story can't be done. This is a better situation than discovering this at the end of the sprint. Start talking to the Product Owner. If one story is blocked, perhaps there is another story you can include in this sprint.

And discuss this at the time of the retrospective to see how to avoid this in future:

  1. If you discovered that one story is blocked, may be you want to do the advance work to avoid such blocking, in future.
  2. If you took on too much work, may be your stories are too large or poorly estimated.
  3. If you discovered more scope than when you estimated, perhaps the team should spend more time in backlog refinement meetings to get the stories ready with clear acceptance criteria.
  • just one thing, the following comment is coming during the planning meeting and not after planning. "If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner." Commented May 6, 2015 at 3:19
  • Yes, but if during the sprint you find that you cannot proceed with a story, you follow this same process and renegotiate with the Product Owner. Commented May 6, 2015 at 17:28
  • "If one story is blocked, perhaps there is another story you can include in this sprint." - is this really a good idea? Shouldn't you continue on to things that are already in the Sprint and then just do another story if you've got time left over at the end? Commented May 8, 2015 at 15:44
  • That may very well be the case. But it is for the Product Owner to say so, keeping in mind the Sprint Goal. Commented May 8, 2015 at 16:29

i think that if it's your project, then you can decide whether it is allowed or not. you should consider the impact of this decision:

  • will it hurt team's focus if they can choose the easy way of abandoning a story instead of fighting for it, or it will reduce the pressure on them?
  • what are the consequences if it will become normal to reduce commitments? how can you avoid it becoming normal?
  • how will it impact forecasts and status tracking? it will reduce velocity for sure, but is there any commitment that is based on the current velocity and it should be reevaluated?

feel free whatever you consider useful for your project, but think about the impact of the change. sometimes it is worthy to change processes.

(btw, if the question is about whether Scrum enables this approach or not, the answer is no - you should strive for delivering everything you committed for - within the limits of sustainability and quality - and if it is not done done for the demo, you should add the remaining work to the product backlog, and eventually to the next sprint's backlog; you should also check whether the sprint has failed)

  • 1
    Though it's your project and you can decide, you're no longer adhering to the scrum values if you consistently push out forecasted stories if they are an essential part of the sprint goal. In the end the aim should be to not have to do this. Commented May 5, 2015 at 8:17
  • Scrum does allow you to renegotiate the scope of the sprint backlog. It doesn't make sense to start work if you already know you're not going to finish it. But it puts a few rules on it (see my other answer). This is a common misconception. But when adhering to the scrum values, the team should figure out a better way so that they're not constantly having to renegotiate the scope. Commented May 5, 2015 at 8:19
  • yes, it is a common critique of my work that i don't give proper respect for scrum values, i focus on project success and customer satisfaction instead ;) also, i consider all methodology as a guideline and a common ground, not something that is set in stone. indeed, Scrum allows you to renegotiate the backlog, but only in exceptional cases (like, team capacity changes, or they finish earlier). however it stresses that team must make effort keeping their commitments, and avoiding this by reducing the sprint scope is not encouraged. Commented May 5, 2015 at 8:29
  • Correct. It should not be the standard. But starting work on something that can't be finished forces the hand of the team and the product owner. That item must now be part of the next sprint or be removed from the increment (or you need to put in place branching practices or feature toggles to handle this). It's better to not start any work you know you can't finish and look for something on the backlog that you actually can finish (unless you'd fail the sprint goal). The scrum framework allows for these changes, but inherently dislikes them. Commented May 5, 2015 at 8:33
  • 1
    It is really interesting to compare the two points of view, they match pretty well, maybe on a different level of abstraction. Commented May 5, 2015 at 11:47

Yes, absolutely you can remove it but will the following understanding:

  • The team understands and agrees why it is necessary to remove it
  • The product owner has been consulted in removing the user story
  • The team and product owner have had a chance to renegotiate the sprint with an attempt to replace the work item with something that is valuable and actionable.

    • All impacted stakeholders have been consulted and/or informed of the change.

-The team takes this as a learning opportunity to make better sprint estimates/commitments in future iterations.

FYI removing the story just to have a cleaner burn-down is not a good reason.


You should not remove the stories to have a cleaner burn down, as this may hide the underlying problem. When it stay on the wall and has not been finished at the end of the sprint, it is a starting point for discussion on improvement. This is meant by transparency.

A better aproach would be to colaborate whith the product owner on reaching the sprint goal, as soon as you detect the problem.

The product owner then can help in either

  1. reducing the amount of work for each user stories, but in a way the sprint goal stays intact or
  2. prioritizing the stories.
  3. The product owner (and only the product owner) could also decide to stop the whole sprint, if he sees no value by proceeding it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.