5 Hidden Costs of Sprint Planning And the Agile Approach That Actually Works

5 Hidden Costs of Sprint Planning And the Agile Approach That Actually Works Hidden cost 1 — Meeting time multiplied by shallow decisions Hidden cost 2 - Inflated estimates driven by groupthinkHidden cost 3 — Hidden work and untracked dependenciesHidden cost 4 — The false economy of large batch planningHidden cost 5 — Overcommitment as a culture problem - [website] ⁠⁠⁠⁠⁠https://www.agiledad.com/⁠⁠⁠⁠⁠ https://www.agiledad.com/ - [instagram] ⁠⁠⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠⁠⁠ https://www.instagram.com/agile_coach/ - [facebook] ⁠⁠⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠⁠⁠ https://www.facebook.com/RealAgileDad/ - [Linkedin] ⁠⁠⁠⁠⁠https://www.linkedin.com/in/leehenson/ https://www.linkedin.com/in/leehenson/

• 0:18Speaker 00

  So sprint planning wastes at least one full day every two weeks for most teams. I don't know that I agree with the word wastes, but that's the word that was presented to me. They said, but Lee, it's a waste. I'm like, it's not a waste if you do it correctly. But it begged the question and they came back and said, that's not a hypothesis. It's a measurable leak of time, focus and morale. If that sentence feels against the green or abrasive, then good. In the next 10 seconds, we're going to either make you close to come closer to the screen and listen to every word that we're saying, or

• 1:04Speaker 00

  you're gonna listen to this and you're going to say to yourself, I've sat in way too many planning meetings. And then rebuild the process that stopped bleeding. So if I want to point out what the problem is, I think

• 1:21Speaker 00

  the context behind this was one of my valuable listeners sent in an overview of an article, not even a whole article, because they said the article is long. But they went in and said that sprint planning is intended to create clarity and alignment. Instead, sometimes it produces a long meeting that doesn't really solve a problem. A backlog that's full of assumptions and optimistic estimates. Teams that start sprints with hidden, untracked risks. And a false belief that commitment equals predictability. Those items add up over time. They are not abstract. They are daily drag on delivery velocity, developer focus and product quality.

• 2:03Speaker 00

  I get it, but the person who wrote the article tried to point out five hidden costs to sprint planning. So what I'm going to do is I'm going to review each one and then I'll give you my feedback or my context on it. Then we'll move on to the next one. Sounds good. All right, let's go. So let's start with number one. Number one says, meeting time multiplied by shallow decision making. This is interesting. Teams me for two or four hours every sprint. Those hours are expensive and engineer time. The worst part is that many decisions are shallow because the team lacks the context they need to make a fluid decision. Everyone is present, yet the product owner, a few domain experts and a noisy debate decide priorities without deep data.

• 2:47Speaker 00

  Their recommendation is to move to a two-step planning ritual. Step one is pre-planning for 30 minutes where a product owner, engineer, designer, surface unclear backlog items and define acceptance criteria, and then commitment session for 30 to 60 minutes where the team agrees on a scope using pre-prepared cards. Okay, let's stop. This sounds a lot to me like the backlog refinement session where I'd say the team can spend up to one hour per team with the product owner to get this done, and that the product owner should never do it by themselves, that the product owner needs a POB, product owner, business analyst, functional analyst, technical analyst, to get involved to help them with that pre-planning session. The second part is the actual sprint planning meeting where it's six steps, it's a

• 3:32Speaker 00

  commitment session, and that's exactly what it's designed to do. So I think that if we're going to talk about this commitment piece, that we need to be careful because I think that right now what we're seeing is this person is advocating that we shorten this meeting and have a different group of people involved. That's the part that's kicking me. So for me, I think that the team does need to have this meeting and they do need to agree on a scope, and I can usually get it done in 45 minutes. So I don't know that I disagree with this one. I'm looking at it now, and this is almost exactly what I teach. I just think if

• 4:14Speaker 00

  their point is it doesn't have to be a four-hour meeting in the nth degree of detail, I definitely agree. Let's move on to number two. Inflated estimates driven by group think practices.

• 4:26Speaker 00

  You know what? This is wild. I think I'm going to agree with this person. When a whole team tries to estimate together, the loudest voices anchor the numbers. That anchors, that anchors scope and not reality. Story points cluster around the anchor and rarely is the true complexity surface. If you use independent asynchronous estimation, like a planning poker app or a silent story point vote. Okay, let's pause. I thought I was going to agree, but now, now I don't. So one of the things that I promote is rapid release planning. And this is where we're getting those estimates in. Now, what's interesting is I do prescribe and say that we should allow product owners to place an initial estimate on it after consulting with their BAFAT.

• 5:11Speaker 00

  And if they do that, then you're going to get two separate estimates that are asynchronous. So in that sense, I agree. However, I do believe that the team knows more about the work than the product owner does. So it's imperative that we let the team go in together and do that type of estimates. So what I'm saying is yes and no. Again, we're back at the same spot. I holistically agree with what's being presented here, but I want to make sure that we're not throwing a baby out with the bathwater proverbially, right? All right, let's go to the next one. Number three says hidden work and untracked dependencies. Here we go. So one of the things that I've been talking a lot about lately in my sessions,

• 5:55Speaker 00

  in my workshops with my teams and with my people, is the concept of hidden factory. Now, hidden factory is where you make mistakes or make changes and you don't document those. And then what ends up happening is the same mistake repeats itself and you wind up having to fix it again. So what I'm getting at here is hidden work may be a little different. Let's take a look. A sprint's full of ticketed work and it can still fail because of external dependencies. Infra tasks are unplanned bug fixes that nobody budgeted for. And sprints show high planned completion, but many tickets carry multiple block states. The fix is explicitly allocate 10 to 20% of your capacity for unplanned work and external dependencies

• 6:40Speaker 00

  or create an explicit dependency card lane. Okay, let's pause. Hidden cost number three is advocating for scrum bond. And once again, I never thought in a million years when this article was sent to me that I would be agreeing with every single one of these. But I actually agree with number three too, but I think that scrum bond is not for everyone. You have to have some level of experience as a team. You've got to understand that you are going to clearly see some things. And there are other things that you're going to be like, whoa, I gotta fix this or we gotta work on this. I guess what I'm trying to say is scrum bond is not for the faint of heart. There I said it. Does it work?

• 7:25Speaker 00

  Absolutely. Is it something more advanced? Absolutely. What I recommend it for every team? Absolutely not. There's no way. But teams that have both planned work and unplanned work can operate in a scrum bond fashion and solve this problem. So that's a good thing. Let's go on to the next one. The false economy of large batch planning. Large batch planning or filling an entire sprint with tasks raises friction of change. Okay, let's pause. I agree with this one. I'm not even going to go there. I tell people all the time, when you go to sprint planning, it's to validate the work that will fall into the sprint that each person should leave with only one thing allocated to them. The purpose behind that, obviously, is so that team members have something primary to work on.

• 8:08Speaker 00

  And they understand that secondary things are going to come up, but they're not focused on the secondary things. They're focused on the primary and they're knocking the primary out. Then when they finish that one, they move on to the next one. And if he gets close to the end of the sprint, they're not pulling a new item into the sprint. They're getting a head start on the first item and the next sprint. The logic there is that the team doesn't feel like there's always this weight hanging over them or that, you know, there's a light at the end of the tunnel, but it's a train coming from the other direction. They hit them. You know, we want to make sure that team members understand and logically say, yes, this is what I need to do. Let's go. Yes. All right, let's. So far, four for four. Let's look at the last one. Overcommitment is a culture problem. Ladies and gentlemen, this is a first.

• 8:54Speaker 00

  This might be the first time I went into an article thinking I'm going to hate it. I'm going to disagree with everything. And I wind up agreeing with all of the all points. Here we go.

• 9:06Speaker 00

  Teams that equate estimate-based commitment with professional pride will repeatedly underperform. Overcommitment damages trust with the stakeholders. Frequent sprint replans and retrospective blame cycles are rampant inside of these organizations. The fix is to reframe commitment as the forecast and make sprint commitments public forecasts with explicit confidence levels. I love this. And what I can tell you is this is exactly what I recommend teams do. I want them to go in with at least 85% confidence. If it's not 85% confidence level, what can we do to get it there? And what I found is when I do this, it helps the team say, okay, it's all right for us to not do that one extra stretch goal.

• 9:51Speaker 00

  It's okay for us to block out a set amount of time to do research. And the teams end up performing better, but I think the bigger thing is that they have the better morale, they're happier, and the organization feels better because they're getting 85% accuracy on their forecasting estimates. So if you want to quickly run through and just recap one more time, we'll do it backwards because it'll be easier. So five was overcommitment is a culture problem. And I want to make sure I don't, because somebody challenged me and they said, oh, so what you're saying is undercommit and overperform? I said, no, I said, get rid of the under and over. I'm saying commit and do. Do what you say you're going to do and get it done. Even if that means committing to one item less, it's better for you to do that than

• 10:36Speaker 00

  have work constantly carrying over. Number four is the false economy of large batch planning. Don't try to fill the entire sprint, well, fill the sprint with work, but don't try to have everyone sign up for all the work up front. Let people swarm to the work as the work becomes available. Number three, hidden work and on-track dependencies. We beat that horse dead. This is just a matter of making sure that you're not...

• 11:01Speaker 00

  Acknowledging the process of hiding things that if there's something that's a dependency documented, if there's a decision that's made, create a change record or even a katakata or something that keeps up with the unplanned and don't be afraid of the concept of scrum bond, right? Inflated estimates driven by group think absolutely happens all the time. And then of course, meeting time multiplied by shallow decision making. This is the concept of having a Pobafata present and making sure that you're doing some type of refinement session after release planning, but before sprint planning so that when a team approaches sprint planning, that work is well defined and easy to manage.

• 11:45Speaker 00

  That's going to do it for this episode. I actually agree. I hope you do too. If you have a topic you want us to discuss, learn more at agiledad.com. We'd love to hear from you. And as always, we encourage you to stay healthy, stay well and stay agile, my friends. Until next time, do take care. Bye now.