Estimating can bring out strong reactions, and for good reason. Mike Cohn and Brian Milner unpack why it gets misused, what “estimate responsibly” really means, and how to use planning to make better decisions without turning numbers into weapons.

Overview

In this episode, Brian sits down with Mike Cohn to talk about estimating and planning in a way that teams can actually live with. They explore why estimates became such a hot button topic, what the “no estimates” movement is reacting to, and how Mike’s thinking has evolved over time. You will hear practical guidance on story points versus time, why teams should estimate only when it helps someone make a decision, and how to keep estimates from damaging trust. They also cover where flow metrics help, where they fall short, and how teams build credibility with leadership through responsible planning.

References and resources mentioned in the show:

Mike Cohn
Estimating & Planning in Agile - A 2026 Field Guide
Accurate Agile Planning Course
Blog: Estimating and Planning in Agile: Why They Still Matter in 2026 by Mike Cohn
Blog: Getting Better Estimates Is Easier Than You Think by Mike Cohn
Blog: What Are Agile Story Points? By Mike Cohn
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.

Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome back Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm here as always Brian Milner and I have the original founder back with us, Mike Cohn. Welcome back in Mike.

Mike (00:12)
Hi, Brian, it's good to see you.

Brian Milner (00:13)
Really glad as always to have Mike here when he can make time for us because Mike has so much wisdom and knowledge to share and especially on the topic that we have for today. We wanted to talk here in this new year a little bit about estimating and planning and really kind of dive into that topic in general and why that still is important, why it still matters here in

in our current day and age. So I guess, Mike, I'll start with this. I know estimating is sort of an emotionally charged topic a little bit. Why do you think it remains such an emotionally charged topic in the Agile community and just in teams when it comes up?

Mike (00:53)
That's a good question. I made a silly little YouTube video years ago where I'd bought a Styrofoam five and I think a Styrofoam eight. They were pretty big, big Styrofoam numbers. They were for like, you know, kindergarten rooms or something like that. And we this video of a guy dressed like a manager beating up a developer with the five and the eight that were representing estimates. Right. And I think a part of it is because that's most developers experience with estimates. You know, they give an estimate.

And they're beat up with it, right? You you're wrong and you can't win, right? You you give an estimate and if you make it, nobody says good job, they just go on their day. And if you miss it, you get beat up with it. Right. And so we were beating people up with these styrofoam numbers. And so it becomes this very emotionally charged thing because I think a lot of developers don't see, you know, what's in it for me, right? What's in it for me with an estimate. And so they're just kind of get opposed to it and they've been beat up by.

too many bad managers with estimates in the past.

Brian Milner (01:51)
Yeah, I try to explain that to people in classes sometimes that, as a developer, as a past developer, I know like we're always looking for the stick, right? The stick is around the corner and we don't know how far around the corner, but we know that we're gonna get beat at some point. And we're just a little leery that this might be just another way to, you know, facilitate the beatings if you will. Yeah. I know one of the...

Mike (02:02)
you

Yeah. Yeah.

Brian Milner (02:17)
There's a lot of different thoughts and opinions on this in the Agile community. There's the no estimates movement and planning, that kind of thing. What do you notice that people are reacting really against when they argue for those kind of approaches?

Mike (02:31)
I think they're a reaction to excessive estimating, excessive planning. And I've written about this essentially probably since my estimating and planning book and talk about it at conferences since the early 2000s, that you want to estimate so that you can make a decision. You don't estimate just for the hell of it. mean, estimating can be a useful activity. Planning can be useful, but they can very easily cross over into waste.

And I don't want to have a team spend time, waste time estimating just so the boss has a number they can beat us up with later. Right. Or so the boss can, you know, sleep at night. Right. You know, and the boss probably was a developer who was asked to estimate when he or she was younger. And now they ask their team to estimate out of habit. Right. And no, you estimate so you can make a decision. And if no one is going to use the estimate to make a decision, then don't estimate.

Right. It's a waste of time. And that's where I'm on board with the no estimates thing. Um, lot of the no estimates people are, I don't know, it's the world's most clickbait title because it's not really about no estimates, about fewer estimates in most cases. And totally, totally on board with that estimate to make a decision. Don't estimate just to have a number.

Brian Milner (03:48)
Yeah, I remember years ago that I actually went to a local meetup group here in my home area and Woody Zool was there and he was talking about the no estimates kind of approach to things. And I remember thinking, I'm ready to fight this guy. Like I had never met Woody before and I thought, know, I'm an estimates kind of person. I think estimates make sense and I'm ready to, you know, have that discussion. Right. But then Woody comes out and he's this nice

Mike (04:09)
To battle.

Brian Milner (04:14)
He's like everyone's grandfather. He's just this kind person. He's one of the kindest people I've ever met. ⁓ And he starts talking about it. And I remember writing in my notebook from that session that it seems to me like the sum of this is really estimate when there's value to estimating. And I thought, I agree with that. I don't have any problem with that.

Mike (04:20)
Mm-hmm.

Yeah. Yeah.

hashtag fewer estimates doesn't go anywhere. So it's a click baity thing to get attention and that's fine. mean, Kent Beck acknowledged when he called it extreme programming that it was going to get a lot of attention, right? That was why he named it extreme programming to get attention on his process. So there's no problem with that, but you know, it does harm when people don't really understand the nuance and think that it means we throw all estimates out. Estimates can be helpful. We just don't want to overdo it.

Brian Milner (04:40)
Yeah.

Right.

Yeah, yeah, kind of like it's, it wouldn't be quite as much of click bait to say Agile is done wrong. It's much better to say Agile is dead. And then I'll explain to you why it's really just Agile done wrong. Yeah, well, back to thinking here about estimation a little bit. I know that you've been talking about this for a long, long time. And this has been something that has evolved a little bit. And I want to kind of focus a little bit on that for,

Mike (05:11)
Yep.

Brian Milner (05:32)
portion of the show to talk about really how thinking on this has evolved over time. So how's your thinking on estimating and planning changed over the years, especially recently?

Mike (05:43)
been a number of things. When I wrote my book on Agile Estimating and Planning, I wrote it with, there were two chapters kind of in the middle. One was about story points. One was about estimating ideal days. And I was totally open through the rest of the book on either of those approaches working well for estimating. And I've really switched around on that where I don't think talking about ideal days is a valid approach because it just leads to too much confusion over who's day and things like that. And so.

I like the abstraction layer of a story point. I think one of the mistakes I made in that book was not being clear enough about what story points really are. mean, I did write it in there, but I just didn't, you know, go over it again and again to really make the point clear. And it's led to a lot of confusion where people just think, you know, story point is a day and, and crap like that. And that's really caused a lot of harm.

in the agile world and I'll go into companies, oh, we do story points. We, you know, set one story a point equals a day. Um, and it's like, no, can't do that. And when we were trained by somebody who said they read your book or something, um, and it definitely does not say that. So, um, I've become more adamant about, um, trying to help people understand what story points really are and they're a measure of effort.

where effort is defined as a combination of complexity, risk, uncertainty, and volume of work. We've to mix all four those factors together and come up with some sort of effort estimate. And that wasn't clear enough in some of my early writing. Another big thing that I've changed in how I think about estimating is a little bit more tactful about sprint planning. And I was pretty adamant for a long time

I think I can, maybe I'm just rationalizing, but I was pretty adamant for a long time about how teams should create a sprint plan that included a list of activities and, and, quick estimates, often referred to them as just guesses, but an estimate for each of the activities on a sprint backlog. And I'm quite open these days to teams not doing those estimates of sprint backlog items. I still do recommend teams start with estimates on their sprint backlog items until they prove to themselves they're good at it.

But once you're good at it, you don't necessarily need to put a number on there. But I never intended those numbers to be much more than guesses, right? They were literally 30 second things. They weren't like big discussion estimates.

Brian Milner (08:08)
Yeah. Yeah. By the way, I don't think I mentioned this yet, but if you're listening along to this and are interested in this topic, we did put together a PDF for this episode as well that you can download. Look in our show notes. It's really kind of a field guide to estimating and planning here in 2026. So just know that that's there in our show notes. But Mike, I agree. I think there's an aspect of this that when it comes up in classes, I actually have started begging people to kind of

do something here and that is that if you're you're making that connection if you are if your organization has a Story point equals this amount of time no matter what that is hours days, whatever it is My my ask my beg that I make in classes just estimate in time

Mike (08:54)
Yeah, absolutely.

Brian Milner (08:56)
I haven't had anyone, and so this is a challenge to the audience here. If anyone knows of a benefit of making that conversion, then please let me know. But I don't know what the benefit is. It's just confusing to the developers. If, this is going to take me about, I don't know, 10 hours, if story point equals six, let me do the math. I just don't know what the benefit is.

Mike (09:16)
Yeah.

There's no, there is no benefit. That's just extra complexity, right? If you're estimating an hours, just use hours and don't be apologetic about it. We're estimating hours and that can work for some teams where that becomes a problem is when you have the superstar and the junior intern, right? Because the superstar says two hours, the junior intern says two decades, right? I mean, you know, they're just not going to agree on things. if he's that bad, if she's that bad, whether or not our junior intern.

but you know, if somebody says two hours and somebody else says 20 hours, how are they going to come to agreement? Right. They can't. Right. But the superstar and the junior intern can, we're dealing with the extremes here, look at things and say, this thing will take twice as long as that other thing. Right. And that's, that's the benefit to points.

Brian Milner (10:02)
Absolutely agree. Well then let's reframe it a little bit. Let's reframe estimation. If it's not really about prediction, what would you say it really is for? What do we use estimation for?

Mike (10:14)
To make the decisions that we've talked about, you want to estimate so that you can make a decision. We put a product backlog item and we call it three points. And the product owner says, three points, cool, I want that thing. If we had said that thing was 20 points, the product owner might say, nah, that's too much. It's not worth 20 points. And so that quick estimate on a product backlog item lets the product owner know

how much they want the thing, right? It's desirable, but not at that price, right? I'd like a Ferrari, not at that price, right? So it helps us make those decisions. We put a estimate, if we do it in sprint planning, if we put an estimate on a sprint backlog item, say a programmer says it'll also take eight hours and the tester says it'll take 12 hours, the programmer might say, wow, 12 hours to test that, you know, is there anything I can do to make that easier?

for you to test. Well, if you coded me a couple of hooks, I could cut the testing time in a fourth. Oh, let's code those hooks in there. And we add an hour to the programming time and we cut the testing time by 75%. So those estimates can help us make decisions.

Brian Milner (11:26)
Yeah, I agree. And I think that's kind of the focus is on the purpose and what are we trying to accomplish with this. And if it's to make a decision, then yeah, we should keep that as our central focus. Is it possible then to make those kind of decisions without estimation?

Mike (11:45)
That's a great question. It's a subtle one. This is where, you know, I will have arguments to people that are kind of opposed to estimating. And they'll say things like, no, we don't estimate. make all of our product backlog items the same size. Well, think about what's going on in someone's head to make all their backlog items the same size. They're looking at a new item and saying, is it the same as all the others? No, it's too big. I better split it up. Okay. Let me split it up. Now let me split it up. I got to make the new, the new splits about the same size.

Right. They're, they're implicitly estimating. Right. Whereas in my world, we might just say, okay, the bulk of our backlogger threes, this one's a little bigger. It was called a five. Right. And we're done. It's, it's easier. Right. So I don't, I mean, we're estimating all the time, you know, you and I scheduled time to do this, this podcast recording.

I had a doctor appointment about a half hour away from me this morning before we started recording. had to estimate how would my doctor take, how long would take me to get home? things like that. Right. So we're asking all the time. We don't often talk about the estimates. They're just implicit in our head, but I don't think you can get away from estimating. You're doing it implicitly, whether you want to admit it or not.

Brian Milner (13:00)
Yeah, I agree. And I've talked to some of those people who do that same thing, who say we get it all down to the same size and so everything's a one. And my response generally is, well, that's great. I mean, if you can do that, then I think there's value in being able to do that. I can only speak from my experience. I haven't worked on a team where we've been able to get everything to the same size. There's just always some things that are bigger than others and we can't split those things further.

So that's why for me, think estimation's better. But I mean, if I was on a team where we could get it all down to one, great. I don't have a problem with that.

Mike (13:32)
Yeah,

but I'm with you. I'd rather have the thing where we say, okay, everything's one to five, right? If that's what we want to do, right? We want to target things that are twos and threes. Of course we have trivial things. Let's call them one, right? Of course we have things that are a tiny bit bigger. We'll call them fives, right? That'd be a better approach to me. It'd be faster, be faster.

Brian Milner (13:52)
Yeah. Well, that leads us to kind of another big area because I know one of the things that people often talk about with estimation and planning is that it is maybe it's anti-agile. know, like it keeps you from being adaptable. And it's framed in that kind of light of it being, you know, an obstacle to being adaptable. Do you think that's actually true?

Mike (14:11)
So it's a good, it's a good observation. Some of the early days of agile, there was a lot of talk about what do we call the enemy? Right. and some of it was, you it was agile versus plan driven. was, agile versus waterfall. you know, what, do we call the opposite? And plan driven was one of the ones that was discussed. And I don't think we want to be plan driven, right? I mean, we don't be driven by the plan, but I think.

A reasonable amount of planning. again, it can easily be overdone. A reasonable amount of planning improves our agility or our adaptability. know, think about a team that's planning to summit Mount Everest, right? They have no idea when they set out, all of the conditions they're going to face, right? And the troubles that they're going to have, the obstacles they're going to encounter. And so they plan, right? They plan that the trip.

trip up the mountain might take longer than expected, right? They plan by taking extra supplies that they can use on the way down, right? And so that planning improves their agility and improves their ability to adapt to the conditions.

Brian Milner (15:17)
Yeah, I agree. It's kind of like this concept of the sooner we know about a problem, the more options we have to actually address that problem. And I think that's one of the things that this gives us in that kind of planning is that if we kind of can look ahead and see, well, this is a potential issue. Well, now we can have more possible avenues to solve that problem rather than when we're right up against it.

there's maybe only one way to deal with it.

Mike (15:45)
Absolutely. Absolutely.

Brian Milner (15:48)
Well, I know one of the other areas that's kind of the hot button topic, or I hear this talked about quite a bit, I get asked about this in class, is kind of flow metrics. And I know that's a popular thing right now. So I'm sure people are kind of interested in your thought on that. From a flow metrics perspective, what do you think it does well or what do you think it struggles with and falls short with as a way of planning?

Mike (16:10)
think tracking your flow is a great thing to do. I don't think it should be the only thing you do. When we have novel work, when we're doing something that's completely new, there's extra complexity there. And I don't think the flow metrics handle that as well. having kind of more traditional metrics, having estimates, and you

Balancing them out right with the flow metrics is going to be the way to go. You know, this is the thing with any sort of metric or measurement. You never want to rely on just one thing, right? Think about, you know, you get on an airplane and you look up and see how many controls or gauges the pilot has. It's like, holy cow, right? You wouldn't want to fly a plane with one gauge, right? You want to have multiple views of where you're at. And so flow metrics are a good supplement, but I think they help ground conversations.

but I think estimating more traditional estimating helps us think through the challenges that we can anticipate with, with work, especially novel work.

Brian Milner (17:11)
Do you think these two kind of complement each other, flow metrics and estimating with some story points?

Mike (17:16)
Yeah.

Yeah. I think they can be, they can be a good balance. Right. It's certainly useful to see how many items are flowing through our process. Right. but it's also good to see, you know, what the sizes of those, those things are.

Brian Milner (17:27)
I just want to mention again, if you're listening into this, we do have a PDF about this very topic that you can download in our show notes. So make sure you take a look at that if this is a topic you want to go a little bit deeper on. Let's talk a little bit about the human impact of this. What do you think happens, Mike, to teams when they're planning an estimation are kind of stripped away entirely?

Mike (17:51)
Well, this is, this is a little bit back to where I was, where we started, where I was saying that developers kind of say what's in it for me, right? I estimate what's in it for me, right? You know, I gave the boss a number, they're just going to beat me up with it. There's no benefit. So we need to get to a point where developers understand that estimating well or planning well, even more importantly, planning can be beneficial. Imagine to them beneficial to them. Imagine a team that's just horrible at.

at estimating, they're just horrible at estimating and planning. They're never right. And the business comes to that or that, that development team and says, Hey, we need this in three months. And the developers say, can't be done. Can't be done. Well, I think the business has every right in the world to say, it a try. Right. Cause this team's never been right in the past. Right. If they say it can't be done in three months, maybe it can go give it a try. Right. And so in those organizations, we see businesses, leaders putting a lot of pressure on the team to

Brian Milner (18:39)
You

Mike (18:48)
Go do it anyway, go give it a try, make it happen. Now imagine a different scenario where the team is good. Not perfect, no team's perfect, but they're good. They say something will take three months, it takes almost three months. They come in a little bit early. The next thing they say it'll take two months, and say it takes two and a half. Again, they're not perfect, right? But they're pretty good and they built up this track record of being pretty good. And now the business comes with that same new project and says, can we do it in three months? And the team says no.

Now the business is going to listen. They're going to say, oh, okay, it can't be done. What would it take? And here's the key thing. What would it take for us to get it done in three months? Well, if you relax this one requirement, right? Or if we could stop doing second level support of the other product for two months while we work on this, right? If you, if we have one more person, uh, whatever, whatever it is, right? We had different tools. So, but now it's a collaborative discussion of what can we stakeholders and team do.

to achieve that three months or maybe we can't do it in three, but we can do it in three and a half. And it's a collaborative discussion now. Whereas before when the team was bad at estimating our plans, dictate, make it so, right? That's not a good position to be in. when we drop the planning or we just kind of give up on it, we're losing a way for teams to establish credibility.

Brian Milner (20:09)
Yeah. I think you're right that it does. It has quite a lot of impact on just the morale of the team and kind of how they approach the work and everything. This is kind of a bonus side question here for you, Mike. Just want to see what you'll do with this. But I know sometimes I will talk to leaders who say that their team is bad at estimating, that they don't estimate

points well, that they want them to be better at estimating points. And I'm kind of curious what your take would be on that. Is it possible for people to be better or worse at estimating points?

Mike (20:46)
absolutely. But it depends on why they're wrong. So let's just talk about a few things there. So the most common thing when I hear that a team is bad at estimating and they're using story points, it's probably because they do not have a solid understanding of what a point is. Right. You've got people in there thinking that their time, other people are thinking they're just complexity, right? Points are not complexity. Complexity is a factor in the effort that is a point.

so you end up with these, these funky inconsistent, incompatible definitions. And that's of course going to lead to problems. Right? So what I want to make sure people do is that they have a common understanding of what a point is. And if you sit in on a meeting like that and you ever hear somebody say, well, it's five points if I do it, but 10 points, if you do it, you know, they don't agree on what a point is, right? Because that's the antithesis of a point. And so I'd want to make sure they had a very clear definition.

of a point and that's from teaching this for so many years. That's hard. there's this, there's this magic point people have to get to with points. And I see this when I'm, when I'm teaching, when they, when they get it, it clicks and all of a sudden every single thing about estimating makes sense, right? Everything makes sense, but they have to do this magic inflection point. And I contrast that with something like stories and backlog management that I teach as well. Those are.

Those are like golf, right? You can always get better at writing stories. You can always get better at splitting. They're very linear skills. Just keep getting better at those things with practice, estimating there's this magic point and you have to get the team members, ideally all of them, at least a majority of them to that inflection point. If we've done that, there's all sorts of things that we can do to get teams to create better estimates. I'll just share two. One is a technique called unpacking.

what unpacking entails is discussing the components of the work, right? to do that big feature, we'd have to do this and this and this and this, right? Don't necessarily write them down, but just talk about them and then go back and estimate the big thing. So don't estimate the small things the unpacking refers to identifying those small things. So you unpack the big thing, identify the sub steps and then re-estimate the big thing. That has been shown through academic studies to be a way to improve estimate quality.

Another thing that teams can do if they're bad at estimating is to make sure they agree on what they're estimating. And you might have somebody on your team who's very conservative, very nervous, and they're estimating kind of the worst case scenario, right? Not normally at the worst case scenario, but kind of like the 90 % scenario, right? You know, they're thinking about all sorts of things going wrong. You might have somebody else on the team estimating the most likely scenario. What most likely will be done in three days, right?

Um, you might have other people in there thinking about the median estimate, the kind of 50 50 number, 50 % of the time it'll take more 50 % of it'll take less. These are all different numbers. And if you have that going on, on a team, you're going to have fights, you're going to have arguments. And so if you're in with a team and you see them having big discrepancies in their story values because of that.

Brian Milner (23:56)
Yeah, yeah, I just wanted to see what your answer was on that because I know a lot of times I get that question in classes as well.

Mike (24:02)
I can go on and on. I think I've

got a video of about five things to do to get better and four things to stop doing that'll get you better.

Brian Milner (24:11)
That's awesome. Well, that kind of naturally leads us to talking about the misuses of this as well, because I think a lot of times that's where a lot of the problems come from is just sort of a misunderstanding or misusing of story points. know for one, I always know that there's a misunderstanding and misuse when I hear developers talking about, want to get credit for the work from this sprint. I know that there's a misunderstanding or misuse of them.

If the misuse of these is so widespread, why do organizations keep asking for story points then?

Mike (24:46)
Because they, I mean, I don't know that organizations ask for story points, organizations ask for plans, right? You know, give me a date, right? Give me a date, right? When will you be done with this stuff? And it's because, I mean, that's, you know, to a large extent, that's how organizations run. And, you know, we can pretend that it should be, well, we'll just deliver features as fast as we can. But there's often other parts of an organization that need to coordinate with the release of something, right? We might need to train users on it. We might need to.

Brian Milner (24:51)
Well, that's true, that's true.

Mike (25:15)
update website documentation about the new features, All sorts of things. so having some sort of plan, you know, it doesn't have to be very far into the future, but some sort of plan is extremely helpful.

Brian Milner (25:27)
Do you think estimation can become harmful in organization and what kind of things would signal that it's kind of, it's taken on a harmful turn?

Mike (25:36)
Well, that's when you're, when you're running around beating the team up with the five and the eight that I mentioned, right? Um, you know, when, numbers, when estimates are used to punish developers, right? You know, when exceeding an estimate is viewed as a bad thing, right? It's an estimate you're going to be over. Right. And I just talked about most likely median and 90 % case estimates. I recommend teams estimate at a 50 % level. Now we do that so that we can plan it more of like a 90 % level.

Brian Milner (25:39)
Yeah.

Mike (26:06)
But individual estimates, if we're doing them at a median, that means we're going to be off half the time, right? If we do it well, we're going be off half the time. And most teams would be off a little bit more than that because they're not particularly good yet. And so we have to, in some ways, celebrate the fact that some of our estimates were over, right? What we want to have is a process where we have some over, some under, and they balance out, right? And that's where a lot of teams go astray. So I think, you know, punishing people for high numbers.

I'm punishing teams for high variance in their work. I have tracked hundreds of teams, which means thousands of sprints. And what I noticed was that a typical velocity for a team will bounce around in a plus or minus 19%. That's very precise. So it's rounded up and called 20 plus or minus 20 % range.

What that means, if you've got a team that averages 20 points, next sprint, they might get 24. The next after that, they might get 16. And those are not good and bad news. They're just random statistical variants or variability. And, um, you know, when a team is bouncing around in a range like that, that's a good thing, right? And you don't want to punish a team for, no, you were two points under. only got 18 done. It's like, yeah, that's random variation.

Brian Milner (27:22)
Yeah, yeah, I agree. It does have the propensity to be misused. And I do think that there are a lot of situations where it has been misused. And people come out of that, situations and think, estimation itself is bad, but it's not really the estimation. It's the way you're doing it. That really ends up being the problem. ⁓

Mike (27:41)
Yeah, there's just

numbers. It's all about how the numbers get used. And that's normally a of leadership intent, right? In how the leaders are intending to use those numbers rather than of the estimates or the team themselves.

Brian Milner (27:54)
Yeah, I kind of think about this in the terms of like, when you see adult beverage ads, it always says, you know, drink responsibly. ⁓ And so I kind of think about that with this as well, not drink responsibly, but use responsibly. ⁓ Right, estimate responsibly. ⁓ Yeah, estimate responsibly. What would you give as advice to estimate responsibly?

Mike (28:02)
Ha ha!

Estimate responsibly. that's your, maybe that's your show title this time.

we haven't talked about this, but I think one of the important things is to think about estimates as ranges. Right. And think about plans as ranges, right? you know, the, the team that I mentioned climbing Mount Everest, I mean, they might have a day they intend to summit, but they're probably looking at a range of days they're going to summit depending on the weather when they get close to the summit. Right. And so user range. so, you know, if we say we're going to finish something, you know, have a, we're going be done in, you know,

two to three months or two and a half to three months, or we're gonna be done in four to five sprints, things like that, or we'll be done in four sprints, but it'll have between this and that much functionality, right? Use ranges on things. Don't overdo it with estimating. Estimate only if something's gonna make a decision. And I think it's very fair for team members to say, would ask for an estimate, very fair for team members to say, cool, we'll do that, we'll do that. By the way, how will this number be used, right?

Oh, I don't know. just need an estimate. like, we're not estimating that. So estimate if there's a reason, right. And I do think that teams can get better at estimating. Most teams don't give their own little feedback loops. You know, why were we off on that estimate? Talk about that in a retrospective, right? Why did we miss a plan? I think it's useful in estimating to state our assumptions, right? What are we assuming will go right? Right.

If we're somebody in Everest, I assume that we're going to have good weather one day during the third week that we're on the mountain, whatever. Right. so I think we have to think about things like that, and use the estimates, the estimating sessions as an opportunity to discuss the work because that's the real benefit is the improved and shared understanding that comes out of those discussions. I've literally done this with, with teams where this was a sprint planning meeting. I'm thinking about where we.

had a Google sheet up, we put all the estimates in the Google sheet for the estimates for the sprint backlog. And at the end of the meeting, I deleted all the numbers. I just deleted that column and the team members are kind of pissed because I'd made them estimate the numbers. And they said, why did you have us do that? And I said, I don't care about the numbers. I just cared if we put the right amount of work in the sprint. And those numbers were there to help us put the right amount of work in the sprint. There we go again, they were about making a decision, right? Those numbers helped us make a decision. Do we have the right amount or not?

Brian Milner (30:24)
Now.

Mike (30:30)
And I didn't want the numbers to remain because then people were going to feel like, no, I said four hours to code that thing and it's going to take me five. I'm going to feel bad or I better rush and be sloppy. So I knew that was kind of a propensity of that team. So I deleted the column, right? I said, this isn't important anymore. We got the benefit out of those numbers were done. So

Brian Milner (30:49)
I love that. I love that because I think that builds trust as well, you know, because of the reason you said you're not, you're not going to hold someone to five hours if they said five hours, it takes what it takes. Uh, and we just learned from it. Um, well, I know these, this is, uh, as we kind of wind this down, uh, there's a lot of hot button, uh, topics on this. I'm sure every time you talk about this, your, your inbox gets flooded with, uh, you know, different opinions and hot, hot takes on this kind of stuff. Uh,

Mike (30:59)
Yeah. Yep.

and insults

and all sorts of things. Yep.

Brian Milner (31:19)
Right,

Please be kind, everyone. Please just be kind, right? It doesn't cost you anything to be kind. ⁓ Right, right. But I think the thing I'd want to ask you, Mike, as we kind of wrap up is if you could give a message to those listening, the Agile community in general on estimation.

Mike (31:27)
Don't insult my mother, you can insult me, Doug.

Brian Milner (31:41)
to help them kind of better understand this or maybe set right something that's not really correct on this. What would be your one message you'd want people to take away and hear from this? Yeah, your one thing.

Mike (31:53)
My one thing,

probably that estimating and planning don't eliminate uncertainty. We're not estimating so that we can predict the future. We're estimating so that we can make decisions. And when we estimate and talk about the uncertainty in items in work, it allows us to navigate that uncertainty. It allows us to create plans to get around it, right? We can, can talk to those assumptions. can, we can.

create a plan together to get around it. But we're not going to eliminate uncertainty and that's absolutely not what estimating is about.

Brian Milner (32:25)
Yeah, I love that. I love distilling it down to just making decisions. I think that's a great way to put it because there's a lot of decisions we make from them, but those are all kind of the driving point of it. We're doing it for this purpose. And if you don't keep that in mind, you can really get screwy with these things.

Mike (32:42)
Yep,

if it won't help you make an estimate or if it won't help you make a decision, don't estimate.

Brian Milner (32:46)
Yeah, absolutely.

Well, this has been great, Mike. I really appreciate you coming on. Now, again, everyone, you if you want to read more about this, look in our show notes, find the PDF for this one, and it'll give you some more insight and information on this. So, Mike, thanks for making time for us and coming on the show again.

Mike (33:03)
Thanks as always, Brian.