On the seventh day of a two weeks Sprint, we realize that 20 percent of the stories cannot be completed.

What is the best action to take?

Is it possible/recommended to cancel the iteration on start a new iteration?

  • 1
    With new teams, its normal for large chunks of the sprint backlog not being achieved. This is why Scrum encourage sprint-wise release planning, estimation, and so on. As you mature, your estimation, plans, and so on become more accurate. By your and you, I mean the whole team, of course. So the first action you take is discuss the issue with the product owner. If the sprint goal is unaffected, you continue working. Maybe the PO can make the sprint goal less ambitious? IMO, sprint is only cancelled by the PO if the business needs change dramatically, rendering the sprint obsolete.
    – Muhammad
    Commented Aug 19, 2017 at 10:09
  • The Scrum Guide "A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense." The Development Team forecasts the items it believes it can complete, this plan can be negotiated with the Product Owner and adjusted as needed. Commented Oct 3, 2017 at 18:18

2 Answers 2


Whether or not you should cancel the Sprint and start over depends on whether or not your lack of ability to finish those stories translates to a lack of ability to accomplish your Sprint Goal.

At the beginning of every Sprint, the Product Owner must define a Goal for that Sprint. It should generally not be simply "finish stories 1 and 2 and 5 and 6 and 7 and 8".

If the Sprint Goal becomes untenable, then yes, you should abort the current Sprint and plan a new one (note that it should be the Product Owner to make this call). If it's still possible to achieve the Sprint Goal, then it doesn't really matter that Stories 2 and 6 aren't going to be done. Just re-estimate them next Sprint (possibly choosing to defer to a later Sprint or remove them outright).

Afterwards, regardless of whether or not the PO decides to terminate the Sprint, the situation should be brought up for discussion in the Sprint Retrospective meeting. If this is a recurring issue, then you need to look into changing your expected velocity. If a one-time issue caused by extraneous events, it should be determined what (if any) measures should be taken to mitigate that same risk in the future.

  • Whether you abort the Sprint or keep going, this should absolutely be discussed in the retrospective. Did you misplan (and if so, how can this be prevented in the future)? Was there an unexpected problem that made the stories slip? etc. (not to be answered here but in the retrospective)
    – Llewellyn
    Commented Aug 18, 2017 at 18:46
  • 1
    This is a solid answer, although it should be noted that only the Product Owner has the authority to terminate a Sprint early.
    – Todd A. Jacobs
    Commented Aug 18, 2017 at 19:53
  • Both good points. I'll update my answer to include them.
    – Sarov
    Commented Aug 18, 2017 at 20:24
  • @Llewellyn, how would you discuss whether a sprint should keep going during the retrospective? The retro meeting occurs after the sprint review; i.e. it is the last event in a sprint. The decision to cancel a sprint is made during the sprint by the PO, as CodeGnome said. In retro, you can of course discuss why the sprint got cancelled by the PO.
    – Muhammad
    Commented Aug 19, 2017 at 9:59
  • @Muhammad Sorry. I meant that something going this badly wrong should be discussed in the sprint's retrospective (whether it was cancelled or not): both the cause of the stories dropping out of the sprint and whether the sprint should or should not have been cancelled. Obviously, that doesn't affect the decision of (not) cancelling this sprint, but it might affect future ones.
    – Llewellyn
    Commented Aug 19, 2017 at 10:23

The Goal is the "Meeting the Sprint Goal," Not Percentage Complete

On the seventh day of a two weeks Sprint, we realize that 20 percent of the stories cannot be completed...Is it possible/recommended to cancel the iteration on start a new iteration?

Sarov already posted a great answer, but I really want to hammer home this point: iterative development is about completing a well-defined goal for the iteration, not about how many stories you complete. With Scrum in particular:

  • Technically, you can successfully achieve your Sprint Goal even if 100% of your Sprint Backlog items are incomplete.
  • You can fail to achieve your Sprint Goal even if 100% of your Sprint Backlog are complete.

In either case, the fact that the stories were the wrong ones or were grossly misestimated is a process problem that you don't want to repeat, but it's irrelevant to the success or failure of the Sprint itself. That's because Scrum is about delivering a meaningful increment of work, and user stories and framework ceremonies are just a means to an end.

Measure Value Delivered, Not Effort Expended

One of the hardest (but most important!) transitions agile teams need to make is the transition from utilization-based resource planning to goal-based planning. This is intertwined with the need to transition from utilization-based KPIs (which are generally only proxy metrics for productivity anyway) to results-driven measures of success.

Teams that measure stories completed as a first-class metric are often abusing velocity as a measure of productivity. These teams are often so busy trying to achieve higher levels of team-member utilization that they focus on parallelizing work rather than collaboratively swarming over it. It's an anti-pattern that usually lends itself to individual task performance rather than delivering a cohesive feature or feature-set as a team.

Review Your Framework Fit

If you find that the Product Owner and the Development Team can't routinely agree on a cohesive goal (hint: "finish 100% of the stories assigned to the Sprint" is not a valid goal) then you need to work as a team to determine if that's because:

  1. the process needs improvement;
  2. the iterative nature of the framework isn't being leveraged; or
  3. the organization has made the wrong choice for what's actually a continuous-flow or repetitive process that isn't really team-based.

Handling Goal Failures

If you're setting the right goals and choosing the right user stories, then it's absolutely possible for a Sprint to fail. In fact, I would estimate that many of my high-performing teams have a 5-8% failure rate, and I would accept up to about 20% on short projects or from less-mature teams.

Keep in mind that in IT, the industry average is a whopping 68% failure rate for entire projects, so the occasional failure to achieve a modest goal is just an opportunity to recalibrate. By failing early when possible you turn a problematic increment into an opportunity to inspect, adapt, and reallocate team resources.

The Product Owner makes the decision as to whether or not the Sprint Goal can still be met. Sometimes the Sprint Backlog can be adjusted to meet the goal, while other times the goal can be lightly tweaked to manage scope. However, if it turns out the goal was the wrong goal (which happens more than you might think) or there were unforeseen challenges—or sometimes even just because business priorities have changed—then it's often better to throw away a few days (or even a whole Sprint's worth) of work than it is to chase sunk costs or previously-expended efforts.

An early termination is just a way of saying that something has changed, or the plan was wrong. The Product Owner and the team back up, reassess, and replan based on what they know now rather than what they knew when the previous Sprint was planned.

As the Scrum Master, ensure that:

  1. Every early termination is formally called for by the Product Owner, regardless of who identified the problems that resulted in the early termination.
  2. The termination is immediately followed by a retrospective to identify what went wrong and how to address it. (NB: This is about process improvement or communication, not about blame.)
  3. The Sprint Retrospective is followed by a return to Sprint Planning and a brand-new time box for the following Sprint.

The fastest way to Scrum project failure is to treat time boxes as flexible or optional. The second-fastest way I know is to skimp on replanning at time box boundaries.

See Also

Scrum Events: Cancelling a Sprint

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.