Mike Cohn Asks Who Should Cancel a Sprint, he`s Asking the Wrong Question
Mike Cohn wrote about who has authority to cancel a sprint. Product Owner or Scrum Master? He argues it should be the PO.
I read that and almost laughed. Not because he's wrong. Because he's debating rules of a game that nobody's actually playing.
We had a project. Four months timeline. Scope was clear, team had estimated, sprints were planned. Everyone agreed it was tight but doable.
Then someone had a meeting on the 14th floor.
Next morning, new timeline: two months. Same scope. Same team. Half the time.
The Scrum Master called us together. Explained the situation. We pushed back. Not complaining — math. The work is X, the hours are Y, two months doesn't fit.
He nodded. He understood. Then he said what Scrum Masters always say when the pressure comes from above: "I hear you, but this is direction from leadership. We need to find a way."
That was it. Discussion over.
We found a way.
Six weekends in a row. Not because anyone held a gun to our heads, but because that's what happens when "commitment to the sprint" meets "direction from leadership." You absorb it with your body.
We shipped on time. The retro called it a success. The Scrum Master got praised for "guiding the team through a challenging period."
What nobody tracked:
The week after launch, two developers started looking for other jobs. Bugs that should've taken hours took days because everyone was running on fumes. The next three sprints were a disaster — not because the team got lazy, but because you can't burn people for six weeks and expect normal output.
We "delivered." We also broke something that took months to rebuild.
Maybe you've been here.
Maybe you've sat in a planning meeting knowing the timeline was fantasy. Maybe you've said "this won't work" and watched your words disappear into the air. Maybe you've worked weekends to hit a date that someone invented in a room you weren't invited to.
And maybe part of you thinks: I should've pushed harder. I should've refused. I'm part of the problem.
Here's what I want you to hear: you are part of the problem. But it's not your fault.
The system is designed to make you absorb the pressure. The Scrum Master is supposed to protect the team, but he reports to someone who reports to someone who set the deadline. The framework says estimate honestly, but everyone knows low estimates get questioned and high estimates get cut. The retro asks "what went well" while everyone's too tired to say the truth.
You're not failing the system. The system is failing you, and it's using your professionalism against you.
I didn't quit after that project. But I changed.
I started protecting my team differently. Not with arguments or principles. With numbers.
When leadership wanted to cut timelines, I pulled up the data. Last quarter we rushed delivery on Project X. Here's the bug count in production: 340% above baseline. Here's the feature velocity in the two months after: dropped by half. Here's what that cost in developer hours, customer complaints, emergency fixes.
Then I asked: do you want to do that again?
Numbers don't argue. Numbers don't get emotional. Numbers don't get labeled as "not a team player." Numbers just sit there and make the point.
I started adding buffer to estimates. Not lying — accounting for reality. Reality includes interruptions, bugs in old code, people getting sick, requirements changing mid-sprint. Every "padding" I added came from experience, and I could justify each one.
When they pushed back, I showed the evidence. When we delivered without weekend death marches and the system didn't explode in production, that became its own evidence.
It took time. It took building credibility. It took losing some battles to win the war.
But now my team ships without burning out. Not because I found a better framework. Because I stopped pretending the framework would protect us and started doing it myself.
Mike Cohn asks who should have authority to cancel a sprint.
I think that's the wrong question.
The right question is: when someone sets an impossible deadline, who in your organization can push back with evidence and actually be heard?
If the answer is nobody, then it doesn't matter how elegant your Scrum is. You don't have a methodology. You have a pressure-absorption system with daily standups.
But if you're a lead, a senior dev, someone with even a little bit of credibility — you might have more power than you think. Not to win every battle. Not to fix the whole system. But to protect your team a little more than you did last month.
Start tracking the real costs. Bugs after rushed releases. Velocity drops after crunch. Turnover after death march projects. Build your case with evidence.
Because "we need more time" is an opinion. But "last time we rushed, here's what it cost" is a fact.
And facts are harder to ignore in a meeting on the 14th floor.