Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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?
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.
@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.
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.
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.
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.
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.
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)
