What to do when mid-sprint, you realize some stories won't be done?

Question

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?

Answer 1

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.

Answer 2

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