Agile and Lean wisdom teaches us that hitting the stop button is something best avoided.
Seymour Cray’s 1964 supercomputer had an Emergency Stop button on the operator’s console. It’s at 5 o’clock to the right-hand ‘bug’s eye’. The CDC 6600 ran silicon transistors rather than the high voltage and high temperature valves of earlier computers, so what would cause anyone to press stop?
Workers at Toyota’s plants are told of the cost per minute, of stopping the production line. Any worker can pull the line-stop cord.
In Agile Scrum, the Product Owner is the only person who can halt work mid-sprint.
Hitting stop initiates a costly cycle of waste: machines and people pause mid-task, often at the most inconvenient moment; people get diverted by the cause of the stoppage; restarting and getting back ‘up to speed’ mentally or physically takes time; and post-incident reviews represent a substantial investment.
Due to the short duration of Sprints, cancellation rarely makes sense
In the Agile case, the cost of stopping is calculated as: the entire team’s time cost from the start of the sprint, including the planning meeting and preparation for that meeting, to the end of the replacement planning meeting.
It’s the job of the Scrum master or Agile coach to explain these costs to the Product Owner, who should be prepared to explain his/her justification for taking the action. It’s not just the budget-holders that are owed an explanation, but the development itself. All are stakeholders.
What event could cause a Product Owner to stop the sprint?
Hopefully, the business is able to remain committed to its plan for the few weeks until the next planning meeting.
If it seems like too long to wait for the next planning meeting, then consider shortening the sprint length. Three to four weeks is ideal, but established teams may prefer two week cycles. Anything less, and the overhead of meetings gets in the way.
Although I’ve never had to stop a sprint (I’ve stopped the stopping a few times), the candidate reasons I think of would be external. If the client cancels their order, or if legislation renders the product non-viable. Either way, it’s not just the sprint that’s cancelled, but the project itself. In the words of the Scrum guide “a sprint would be cancelled if the sprint goal becomes obsolete.”
What about the discovery of a flaw in the architecture, or uncovering an incorrect assumption?
These incidents do happen and the team should be congratulated for having the courage to raise them. They don’t change the business drivers though, and are best seen as really nasty bugs that need fixing. Usually the Product Owner will decide they can be fixed in a later sprint, and will adjust the sprint / release plans accordingly.