"Scrum Has Too Many Meetings." So Stop Doing Them.

October 28, 2026

This is one of the videos in my Agile-ish series: the good parts of agile, minus the ceremony.

Shameless plug: Want to answer "what's stuck?" and "are we on track?" without a meeting? Honest Cheetah answers the three questions straight from your Azure DevOps or GitHub data. It measures the system, not the people.

▶ Watch this video on YouTube (opens in a new tab)

Here's a really common complaint I hear from devs: Scrum has too many meetings.

Planning, standup, refinement, review, retro... and somewhere in there you're supposed to write code.

Now, as someone who has taught dozens and dozens and dozens of Scrum classes, you'd probably think I'd defend those meetings. Nope. I agree with you.

Slide: 'Scrum has too many meetings.' Oh. Well then stop doing them.

Not getting value from those meetings? Then just stop doing them. Seriously. Stop doing all those meetings.

But here's the deal: you have to quit those meetings with purpose rather than just vibes.

TL;DR

"Stop doing them" is a perfectly good answer. But every one of those meetings had a real job, and every one of those jobs still matters.
Before you tear down a fence, figure out why somebody put it up. (Chesterton's fence.)
Teams don't get hurt by dropping meetings. They get hurt by dropping the goals.
If your board and your data can answer the three questions at any time, you've kept most of what the meetings were for.
Monday morning: pick one meeting, name its job, replace the job, and check a month later that it worked.

But Before You Clear Your Schedule...

Here's the catch in two sentences.

First, make sure you know why you were supposed to do those meetings. And also take note of why your team thinks they're pointless.

Second, if you dump a meeting, you still have to achieve the goal of that meeting.

Because just getting good at Scrum was never the goal. Attending a meeting with a certain title on the invite didn't make it useful. I personally don't care if you do Scrum or Kanban or waterfall or some kind of roll-your-own process. The goal has always been done, working software that makes your stakeholders' dreams come true. Achieve that and no one is going to care what your process is.

On the flip side, if you fail to meet that goal, I'll bet people are suddenly going to care a whole lot about how you work.

Chesterton's Fence

There's an idea called "Chesterton's Fence," from G. K. Chesterton. Here's the gist.

If you find a fence across a road and you can't figure out why it's there, don't tear it down until you know why somebody put it up. There was almost certainly a reason.

Those meetings are the fence. Let's go figure out what they were keeping in.

How the Meetings Became the Point

Back to Scrum and our never-ending series of pointless and boring meetings. How did we get so darned cranky about them?

Meetings are visible, and countable. "Did we hold the retrospective?" Yes we did, and it turned out that we're amazing and on our way to software development awesomeness. (Spoiler alert: probably not.) Checking the box about whether a meeting happened is way easier and more visible than figuring out whether you actually got any better at delivering.

Lots of teams learned the ritual, not the reason. Plenty of teams learned the meetings without ever learning the purpose. Or they learned the meetings and forgot the purpose. Whatever the reason, the meetings were dull, achieved nothing, and distracted from real work. Show up at nine, answer three questions, grab a coffee, sit back down and try to recover from the epic levels of pointlessness you just endured.

The pointless ritual tax. So you just went through a ritual, got nothing out of it, and it feels like a waste of time. It's a tax or a toll you had to pay just to start your day. Of course people want to stop paying the tax.

Every Meeting Had (Has) a Point

Remember: I'm telling you that you can stop these meetings. So let's go through them and re-establish what you were actually supposed to get out of each one. Because you're still going to need the goal without the meeting.

Meeting	Its actual job	Without the meeting
Sprint Planning	Agree on what's next, so you can focus	One ordered list, plus agreed runway
Daily Scrum (aka "standup")	Spot what's stuck before it's late	Watch work in progress and aging work
Refinement	Get work understood and small enough	Make sure work is ready before it starts
Review	Get feedback on done work	Show done work to people who care
Retrospective	Get better on purpose	Watch cycle time, fix one thing

Sprint planning is about "what" and "how." What are you going to work on, and then thinking through how to actually do it. Get it right and you've established priorities and created agreement about the to-do list for the next few weeks.

The daily scrum is about quickly refocusing the team on the goal for the sprint and the plan for the next 24 hours. It's not about status reports or blame, and you should actually care about what other people are saying. BTW, if you don't care what other people are saying, that's a slam-dunk confirmation that your work is organized wrong or your team is organized wrong. I wrote about that a while ago in 5 Reasons Your Daily Scrum Is Boring, and there's a video on what a team actually is.

Refinement. If you've ever heard or ever said "our requirements suck," then refinement meetings are for you. They're not technically required in Scrum, but they're all about making sure your requirements are ready to be worked on. Is our future work understood, small enough, and well-defined enough that we could theoretically start on it?

The sprint review is all about feedback. Feedback on what got done. Feedback on what you're planning to do next. Feedback on the state of the product. It's really not about doing a "demo" of the features. The demonstration is only a means to an end: getting feedback. If you're not getting feedback, it's real tough to know whether you're doing a good job or stinkin' up the joint.

The retrospective. I'll admit it: this is probably the number one most trashable meeting. You've probably already stopped doing them. But the goal is to improve your delivery process and, ideally, limit your mistakes to a single iteration. I've hardly ever seen this meeting done well, simply because it takes world-champion-level people skills and facilitation skills. Honestly, just ask the team as often as possible, "what are we screwing up and what could we do better?" They'll probably look at you and shrug. But at least you asked.

So anyway. Every one of these meetings has a point.

Even the Sprint Had a Job

And it's not just the meetings. Even the sprint itself had a job to do.

The sprint was basically a short feedback loop. Every couple of weeks, you'd find out whether you were building the right thing, and whether you could actually finish stuff.

And it worked like a mirror for your team. Scrum didn't slow your team down. It showed you how slow you already were. And that's really uncomfortable to look at.

So if you want to drop the two-week box, that's fine with me. Just keep that short, honest feedback loop, because that's the part that actually mattered.

The Real Trap(s)

Ok. So you can drop all those meetings. But you need to keep an eye out for certain things going wrong, because each meeting you drop has a failure mode that shows up a few weeks later.

No planning → priorities thrash. Skip the planning meetings and your priorities might start getting unclear. You shift priorities every eleven minutes. Everything's urgent, everybody's juggling, and nothing quite finishes. Watch out for lots of unmerged branches in Git. That's a dead giveaway that your priorities are suboptimal.

No standup → lots of "mostly done." Drop the standup, replace it with nothing, and stuck work just sits there quietly, mostly complete. Everything's 80% done and you're not shipping very often. You probably have build problems and merge problems, too. A whole lot of starting and not a whole lot of finishing. Watch out for too much work in progress.

No review → grumpy stakeholders. Drop the review, and you can build the wrong thing for months before anybody who'd actually use it gets a look. You might have a pile of done-ish features that nobody has seen. Maybe you haven't talked to your stakeholders lately. All of that is a breakdown in the feedback cycle, which usually means your stakeholders start complaining to your boss about where their stuff is.

No retro → the same problems repeat forever. Drop the retro and you get the same problems every single month. Forever. Because nobody's looking for them on purpose anymore.

No refinement → moldy backlog. Stop doing backlog refinement and you probably won't have enough "ready" requirements. You'll hear "our requirements suck," and you'll end up having 80 meetings about what a feature means while you're in the middle of implementing it. Your priorities keep shifting because nobody understands what the product plan is anymore. Refinement keeps the product plan in good shape.

We Saved an Hour a Week. We Lost a Month.

Picture a team that cancels standup to save everybody fifteen minutes a day. Then a few weeks later, they find out one critical item had been stuck the whole time, and nobody noticed.

Whoopsie.

Three Questions Instead of Five Meetings

So how do you keep the goals without the ceremony? I boil it down to three questions, and your team needs to be able to answer all three at any time, without having a meeting.

What are we going to work on? One prioritized list, in order, in one place. Call it a backlog, a to-do list, or a project plan. I honestly don't care what you name it, but you need to have a clue what you're going to be working on for the next month or so.
What are we working on right now? What's in progress, what's blocked, and what's been sitting there way longer than normal? Are we trying to juggle too many things at once?
Are we on track? Are we finishing things, or are we just busy? There's a really big difference between furious activity and actual progress.

If your board and your data can answer those three, you've kept the goals of most of those meetings, whether you hold them or not.

Shameless Plug

I built a tool called Honest Cheetah that answers the three questions straight from your Azure DevOps or GitHub data: what's stuck, what's aging, and whether you're on track. So it can do a lot of the job of those meetings for you. The version for Azure DevOps is free, and the version for GitHub Projects is less free but has a trial. Give it a try and let me know what you think.

What to Do Monday Morning

Alright, let's land this plane. If you want to try this with your own team, here's what I'd do.

Pick one meeting. Probably the one everybody complains about the most. Don't nuke all the meetings at once.
Name its job. Out loud, as a team. What was this meeting supposed to protect us from, or give us?
Replace the job. Decide how you'll still get that result. Maybe it's the board, maybe it's your data, or maybe it's a much smaller meeting.
Check it worked. A month later, check whether you're still getting the result. If you're not, you dropped the goal along with the meeting. Go fix that.

Quick Recap

Too many meetings? Stop doing them. I really do mean that.
But know why each one existed. Before you tear down a fence, figure out why somebody put it up. Every one of those meetings had a real job.
Keep the goal, even when you drop the meeting. The three questions are a pretty good way to check whether you still are.
Done, working software is the point. Scrum was never about the meetings. It always was about shipping.

Also: if your team just feels stuck, email me. I help teams get un-stuck.

-Ben

-- Is your team drowning in meetings but still not shipping? Want help figuring out which ceremonies to keep, which to drop, and how to keep the goals either way? We can help. Drop us a line at info@benday.com.