#159: Is Scrum Really Too Many Meetings? with Lance Dacy

“Too many meetings” is one of the most common complaints in Scrum teams, but is it really the meetings, or what’s (not) happening in them? In this episode, Brian and Lance Dacy dig into the events of Scrum to uncover what works, what doesn’t, and how to make each one actually add value.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner welcomes Certified Scrum Trainer and Mountain Goat colleague Lance Dacy for a breakdown of the four main Scrum events, and why so many teams struggle with them.

They tackle one of the most persistent frustrations teams face: the sense that Scrum has “too many meetings.” Together, they explore how to reframe these as working sessions, clarify their purpose, and avoid the common traps that drain time without moving the work forward. From sprint planning that skips the plan to daily scrums that lose their rhythm, this episode is full of specific guidance for getting more value out of each event. Plus, hear why retrospectives and backlog refinement are two of the most underrated (and powerful) drivers of team improvement.

Whether you're new to Scrum or looking to reset a struggling team, this conversation will help you re-center on what the framework is really designed to do, and how to help your team do it well.

References and resources mentioned in the show:

Lance Dacy
#138: The Bad Meeting Hangover with Julie Chickering
#156: Making Product Ownership Work in Shared Services with Kert Peterson
Does Scrum Have Too Many Meetings? By Mike Cohn
What Happens When During a Sprint By Mike Cohn
Scrum Activities: An Overview
Working on a Scrum Team Course
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome back Agile Mentors. We're here for another episode of the Agile Mentors podcast. I'm here as always, Brian Milner, and I have with us friend of the show, once again, Lance Dacy with us. Welcome back, Lance.

Lance Dacy (00:12)
Thank you, Brian. Glad to be here.

Brian Milner (00:14)
Always happy to have Lance on. we thought we'd have Lance on. We were kind of doing this thing at Mountain Goat. We're getting ready for the launch of a new course here that's called Working on a Scrum Team. And Lance and I are going to be two of the people that teach that course. And it's going to deal with a lot of like basic stuff that the teams deal with, common problems, common issues, and really how to work together well on a Scrum Team. And one of the things that we always hear questions about is about the meetings themselves. There's kind of three core components there for the Scrum framework. There's the roles, the events, and the artifacts. And so the events, the meetings are one of the biggest kind of focal points. And there's lots of questions about it. So I guess let's kick it off that way, Lance, and just say, what do you most hear? people complain about when they talk about scrum meetings.

Lance Dacy (01:06)
Well, that's the big thing, right? It's like we call them meetings. And the first thing I like to do is try to explain to them that there really aren't meetings, right? So when you hear the idea that you're going to go to a meeting, that's not very exciting, right? You're like, I'm to sit there and not get a lot out of this. So what I would like to say about the, working on a scrum team, I'm going to say it's probably the first course I ever taught as a scrum trainer. And we've been actually teaching it for a very long time. It's mainly just a private. you know, that we go into organizations and help them learn this. So I'm super excited that we're making this available publicly because so often people say, well, I'm a, you know, I'm not a product owner and I'm not a Scrum Master and I want to learn more about Scrum and I don't want to kind of bend to one role. So I am just shouting for joy that we have this one now. And I really hope that a lot of people will benefit if you're a stakeholder or if you're a manager or leader or things like that. A lot of times you have to pick and choose, you know, which class you're going to go to. So

Brian Milner (01:49)
you

Lance Dacy (02:00) "That's one thing, but it helps us address this idea. We kind of talk about it in Scrum Masterclass where people are like, well, we're practicing Scrum now, and now I feel like I got to go to all these meetings. Okay, well, first of all, they're not meetings. Let's get that out of the way. Let's quit calling them meetings. You called them events. I think that's an appropriate term, but I like to call them working sessions. No matter what process we use, you are going to have to get together with your team and collaborate on how we're going to approach building this thing. You have to collaborate on

Brian Milner (02:11)
Mmm. Hmm.

Lance Dacy (02:29)
understanding the needs of the users. Like that doesn't go away. Regardless of the process you use, Scrum just tries to focus us and allow us to get together in specific checkpoints throughout the process. And so if you boil it down, the Scrum framework itself has the four events of sprint planning, daily Scrum, review, retrospective. And then we have this activity, product backlog refinement, which if I had to choose... One of the top two problems with Scrum teams is we don't spend enough time doing product backlog refinement. So a lot of teams even misunderstand what that is. Is that a meaning? Well, not always. It's an activity as well. So I think probably some of the biggest complaints we hear about Scrum as we go to all these meetings. And so I typically like to advise people, you know, if you're going to implement Scrum, get rid of all the other meetings first. Okay. So you're going to do Scrum and

Brian Milner (03:16)
You

Lance Dacy (03:19)
We're gonna do sprint planning at the beginning of a sprint. Every day we're gonna check in on how we're doing against the work that we've collectively decided we could do. We're gonna show our stakeholders at the end and then we're gonna meet at the end and try to figure out how we can get better. There's nothing inherently wrong with that if you don't call it a meeting. Like plan the work we're gonna do for the next, let's say two weeks. Every day check in on it. Show our stakeholders at the end, is this what you wanted? And then what's wrong with getting together and saying how could we do better next sprint? Okay, so get rid of all the other meetings and try to build it into that cadence, if you will. Now, the other side to that is you're going to also have to get together and do backlog refinement, which is estimating, breaking large items down into smaller items. You're going to have to do some level of design on these items. And then, of course, adding clarity and detail to the work items is another big aspect of that. So those aren't meetings. Those are working sessions. So. When I hear most people complain about the scrum meetings, get rid of everything else, only do these. You're going to have to spend that time anywhere, anytime, know, whatever process you use. And if you want to get into the numbers, you know, I hear managers all the time or project managers going, I've got 12 people on a team and they're going to spend, you know, let's say a two week sprint maximum time box for sprint planning is four hours. And that's multiplied by 12 people. That's a terrible amount of time. It's like, yeah, but if you start doing all the math, And you spent the maximum amount of time, which we always would want to lead and coach and train them to spend half of that eventually. But you may have to spend all that time at the beginning, but you don't spend more than that. So, sprint planning kind of just boils down to about 5 % of a 40 hour work week for two weeks, daily scrums, about 3 % sprint reviews, ab