Should I remove a User Story from a Sprint in progress if I know we can't complete it?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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)

Answer 4

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.

Answer 5

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.