4

During Sprints' executions, I used to encounter a problem: the planned Sprint would not be able to finish as forecasted. Then in that case, who is responsible to review and adjust the Sprint work selected?

It is always a confusion in role model, either will it be done by by Product Owner or the Scrum Master?

  • Would the Sprint Goal be impacted by the team's inability to complete all forecast work? – Todd A. Jacobs Jun 22 '18 at 13:09
  • Do you have a Sprint Goal? Is the Sprint Goal not going to be met, or will some of the work in the Sprint Backlog simply not be completed? – Thomas Owens Jun 22 '18 at 13:41
  • You need the product owner to speak on the priorities (what?) in this situation and you need the dev team to speak on the feasibility (how much?) of any new plan. – Kempeth Jun 27 '18 at 14:28
6

The same people who made the initial forecast should get together and figure out how much can still be done.

That is to say: the Development Team should talk with their Product Owner and they should decide together what to do. Only the combination of those two is able to make an accurate idea of what is both doable in the remaining time and most valuable to the end-users.

5

@Todd A. Jacob's comment is particularly important, here.

Is your Sprint Goal in danger of not being completed?

During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Yes, the Sprint Goal is in danger

First, determine the feasibility of being able to complete the Sprint Goal. If sufficiently likely (either as-is or perhaps after making changes to the Sprint), then proceed to the 'No, the Sprint Goal is not in danger' section. Otherwise, abort the Sprint. Then discuss in the Retrospective how/why this happened, and then start a new Sprint with the Sprint Planning process.

Granted, there's some subjectivity on just how to measure 'in danger' and 'sufficiently likely' - these should be defined by the Scrum Team.

No, the Sprint Goal is not in danger

Then you're fine. Focus in the work that is needed to accomplish the Sprint Goal. If there's other included work that never gets completed, it's not a big deal - just a topic for discussion in the Retrospective. Maybe take on less work next time.

We don't have a Sprint Goal

That needs to change, going forward. Not only does the Sprint Goal provide a background to the Team to inform why they're doing what they're doing, it also provides a useful measure to determine the health/usefulness of a Sprint... such as in this very situation you're in now.

As for this particular Sprint, opinions may vary, but in my opinion you should treat a no-Goal Sprint as if it has a Sprint Goal that cannot be completed - and therefore abort the Sprint.

  • 1
    @Erik A fair point; I've updated my Answer. – Sarov Jun 25 '18 at 13:38
  • @onedaywhen This answer does not say that when the Sprint Goal is in danger, the first and only choice is to abort the Sprint. It says that if the Sprint Goal is in danger, you need to determine the feasibility of completing the Sprint Goal and abort the Sprint if achieving the Sprint Goal is not likely. The thresholds for that will vary by organization, and some organizations may choose to rarely or never abort a Sprint, favoring delivering as much done work as possible, even if the Sprint Goal was not met. – Thomas Owens Jun 26 '18 at 11:50
  • I may have not paraphrased correctly; let me try again: You are saying, when achieving the Sprint Goal is unlikely then the Sprint should be cancelled. I have a slight issue with this, please see my answer, which I hope you see builds on your otherwise excellent answer (not a rebuttal). – onedaywhen Jun 26 '18 at 12:30
1

In their answer here, Sarov says:

When achieving the Sprint Goal is unlikely then the Sprint should be cancelled

Let me offer a revised formula

When the Sprint Goal is in danger then invoke your emergency procedure.

  1. Change the way the team does the work.
  2. Do something different.
  3. Get help, usually by offloading backlog to someone else.
  4. Reduce scope.
  5. Abort the Sprint and replan.
  6. Inform management how the emergency affects release dates.

So while cancelling the Sprint is an option, it should be considered only as a last resort.


Cancelling a Sprint when the Sprint Goal is looking unlikely to be met is an extreme position to take. It may ensure you never have a failed Sprint but I don't consider it a formula for success!

It's a bit like saying

When the airliner is in danger of not reaching its destination then immediately conduct a forced landing

From my naive understanding of aviation, it would seem better to - request air traffic control to find an alternative destination - invoke the emergency procedure - etc

The Scrum Guide offers a different formula:

A Sprint would be cancelled if the Sprint Goal becomes obsolete... In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. - Official Scrum Guide

The examples in the Scrum Guide makes it clear the circumstances the authors have in mind are those external to the team. They also make it clear that Sprint cancellation is far from routine:

due to the short duration of Sprints, cancellation rarely makes sense. - Official Scrum Guide

As a Product Owner, I would joke to my Scrum Team that I had a personal goal to one day have the chance to cancel a Sprint, a light-herated way of communicating the idea that a cancelled Sprint is rarely seen in the wild.

Indeed, once (and only once) have the circumstances actually arisen for me. My Scrum Team was halfway through a Sprint whose Sprint Goal related to a compliance project. I was in a meeting with Stakeholders when someone mentioned, almost as an aside, that they cancelled the project that morning because legal counsel had concluded the project's outcomes were unnecessary. But even in these circumstances, we decided as a team to not cancel the Sprint. As is often the case, there were Sprint Backlog items that did not directly relate to the Sprint Goal but everyone still wanted to be completed. Taking out the compliance project items ply left a three days' 'capacity' in the Sprint, and some spikes were played instead, to everyone's satisfaction. A major consideration was not upsetting the Sprint cadence (Mon-Fri etc)

  • This seems to offer a rebuttal to another answer, but does not seem to answer the original question? – Erik Jun 26 '18 at 11:17
  • Yeah, that would be better. Answers or Stack are supposed to primarily answer the original question; enhancing other answers should generally be secondary to that. – Erik Jun 26 '18 at 13:16
  • @Erik "Stack"? First time I've seen that term here. Where's that come from? – Sarov Jun 26 '18 at 13:46
  • @Sarov I meant to say "on Stack", and it's just short for "Stack Exchange Site" :) – Erik Jun 26 '18 at 14:00
  • @Erik Ah, that makes more sense. – Sarov Jun 26 '18 at 14:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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