The meeting got cancelled.
No big deal, right?
Except now the ticket’s unclear, the sprint’s off-track, and Bob is quietly losing his mind.
All because “there wasn’t much to talk about.”
This post is about why cancelling meetings feels harmless—
But isn’t.
When I joined a development team, I found out they hadn’t had a retrospective in over a year.
Not because everything was running smoothly. Not because there was nothing to talk about.
Just… because no one had booked it.
The developers were livid. Frustrated with how things were going—but without a space to say anything, it just built up. Eventually, another teammate and I forced the team to hold a retro.
It was difficult. But it was also a turning point.
We could finally start fixing things instead of letting them slide.
I’ve been both a Scrum Master and a developer. I get it—people think meetings are a waste of time. Especially if they’ve only experienced bad ones.
Weak Scrum Masters run bad meetings. They don’t know the purpose. They don’t guide the conversation. Nothing gets learned, nothing gets solved. So the meeting gets cancelled. And then the next one. And the next.
But bad meetings shouldn’t be cancelled.
They should be fixed.
Because here’s the thing:
The problem that needed the meeting?
It doesn’t go away just because the meeting did.
Some Scrum Masters love to cancel meetings.
And weirdly, they always do it… 15 minutes before.
Why 15 minutes? I don’t know either.
But I do know the default calendar reminder is also 15 minutes.
I’ve seen every kind of Scrum meeting get the axe—
Even the kick-off.
But the most common casualty? Backlog grooming.
And what happens then? Grooming shifts into the daily standup.
Except it doesn’t really fit in the daily. So it happens badly. Or not at all.
The result? Tickets that aren’t properly groomed sneak into sprints.
And then I get developers pinging me, asking what the AC even is.
So we have an impromptu backlog grooming session. Just the two of us.
Not ideal.
Let me be clear: this is not how it’s supposed to work.
But at that point, the horse has bolted.
It’s halfway to Argentina, wearing a bowler hat and a fake moustache.
I do what I can to help.
But what I really want is to stop the chaos at the source—and actually fix the process.
It shouldn’t be like this.
The developer shouldn’t have to guess the AC, write up missing details, or phone around for clarification mid-sprint.
That’s not agility—it’s just chaos.
The Scrum Master’s job is to prevent exactly this situation.
Their role is to protect the team’s time and focus by ensuring that:
- Meetings happen (on time, with purpose)
- Tickets are clear before they land in a sprint
- Issues are surfaced and solved before they cause churn
When the Scrum Master doesn’t step up, the team has to absorb that failure.
And the people who do care (often senior devs, QAs, or helpful humans like me) end up duct-taping the process back together.
That’s not sustainable.
It’s not fair.
And it’s definitely not Scrum.
When I became a Scrum Master, I hated the meandering meetings that went nowhere—and the ones that got perma-cancelled. I didn’t want to be responsible for either.
So I read the Scrum Guide. I wanted to understand the actual purpose of each meeting. It’s easy for them to get off track—but that’s where the Scrum Master should step in and coach the team to focus, understand the problem, and solve it.
I had one rule: I never cancelled the Scrum meetings. Especially backlog grooming. The team always knew the meeting would happen.
But I didn’t run meetings for the sake of it. Backlog grooming always started with a check-in: how’s the sprint going? Are we on track? Then we’d review and line up the next set of tickets.
Over time, we got good at it. Sometimes the meeting became a short check-in, and we’d end early. But we always had the time set aside.
Because even in great teams, things go wrong—not from mistakes, but from complexity. And when I asked in casual catch-ups if anyone had issues, they’d usually say “no.” But in grooming, when there was space and structure, developers would raise questions. They’d flag issues. They knew they could.
And that’s what I liked—not that people were stuck, but that they felt safe enough to say so.
Then we could fix it. Together.
Because if you don’t even know there’s a problem…
how can you fix it?
Developers liked it.
They knew they had space to raise things—without second guessing, or squeezing in ad-hoc grooming calls.
And even though we never cancelled a single meeting… no one ever said it was a waste of time.
It’s almost as if the problem wasn’t having meetings.
It was having the wrong kind.
Some people cancel meetings because they think they’re a waste of time.
But bad meetings are like bad tooth brushing—
frustrating, ineffective, and kind of pointless.
That doesn’t mean you stop brushing.
It means you get better at it.
Otherwise? You end up with black teeth and bad breath.
Scrum meetings are flossing for your process.
Skip them long enough, and everything starts to break down.
The foundations get wobbly. Cracks open. Frustrations build up.
Scrum hygiene isn’t sexy. But you know what’s worse? Rot.
Davide la Locomotive 
Leave a comment