Welcome back, Agile Mentors.
We're back for another episode of the Agiles Mentor's Podcast.
I'm here as always Brian Milner and I have the original founder back with us, Mike Cohn.
Welcome, back in Mike.
Hi, Brian.
It's good to see you.
Really glad as all 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 our current day and age.
So I guess, Mike, I'll start with this.
I know estimations is sort of an emotionally charged topic a little bit.
Why do you think it remains such an Topic in the agile community and just in teams when it comes up.
That's a good question I made a silly little YouTube video years ago where I'd bought a Styrofoam 5 and I think a styro foam 8 They were pretty big big
styrophoam numbers out there for like, you know kindergarten rooms or something like that and with this video of a guy dressed like a manager beating up
a developer with the 5 in 8 that were representing estimates right and i think apart 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 know you're wrong and you can't win, right?
You, know.
you've given estimate, and if you make it, nobody says good job or just go on their day.
And if.
Miss it you get beat.
Up with.
It right.
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 it in for you 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.
Yeah, I try to explain that to people in classes sometimes that, you know, as a developer, or as 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 that corner, but we know that we are going to get beat at some point and were just a little
leery that this might be just another way to facilitate the beatings, if you will.
Yeah.
Um, I know one of the, 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, they argue for those kinds of approaches?
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 talked about it at conferences since the early 2000s,
that you want to estimate so that can make a decision.
You don't estimate just for the hell of it.
I mean, estimations can be a useful activity.
Planning can 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 estimated out of habit, and no, estimate so you can make a decision.
If no one is going to use the estimate to make the 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.
A 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 estimate.
It s 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.
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 remembered thinking, oh, i'm ready to fight this guy.
Like I had never met what he before for, and I thought, you know, am an estimates kinda person.
I think estimates make sense and i am ready, to have that discussion.
Right.
But, and then, then Woody comes out and he's this nice guy.
It's like everyone's grandfather.
He's just as kind person.
One of the kindest people I've ever met.
And he starts talking about it.
I remember writing in my notebook from that session.
That it seems to me like the, the S the sum of this is really estimate when there's value to estimating.
Yeah.
Yep.
Hashtag fewer estimates doesn't go anywhere.
So it's a click baity thing to get attention.
And that's fine.
I mean, Kent Beck acknowledged when he called it extreme programming, that it was going to give a lot of attention, right?
That was why he named it Extreme Programming to Get Attention on his process.
Um, so there's no problem with that, but you know, it does harm when people don't really understand the nuance and think that that means we throw all estimates out.
Estimates can be helpful.
We just don' want to overdo it.
Yeah, kind of like it wouldn't be quite as much of click bait to say Agile is done wrong.
It's much better to Agiles dead and then I'll explain to you why it's really just Agil 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 bit and I want to kind portion of this
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?
There's been a number of things.
When I wrote my book on Agile Estimating & Planning, I rode it with, there were two chapters kind of in the middle.
One was about story points, one was estimated in ideal days.
And I was totally open through the rest of the book, either of those approaches working well for estimations and I've really switched around on that where
I don't think talk 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.
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.
That's really caused a a of harm in the agile world.
I'll go into companies.
Oh, we do story points.
You set one story a point equals a.
And it's like, no, she can't do that.
And 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, 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, volume of work.
We've got to mix all four of 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.
I was pretty adamant for a long time.
And 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 am quite open these days to teams not doing those estimates of Sprints Back Log items.
I still do recommend teams start with estimates on their Sprits Back log 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.
Yeah, by the way, I don't think I've 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 Mike, I agree.
I think there's an aspect of this that when it comes up in classes, actually have started begging people to kind of do something here.
And that is that if you're making that connection, if your organization has a story point equals this amount of time, no matter what that,
is hours, days, whatever it is, my ask, My beg that I make in class is just estimate in time.
Yeah, absolutely.
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 developers.
Hey, this going to take me about, I dunno, 10 hours.
Story point equals six.
Let me do the math.
I just don' know the benefits.
There is no benefit.
That's just extra complexity, right?
If you're estimating hours, just use hours and don't be apologetic about it.
We're estimated hours.
And that can work for some teams.
Where that becomes a problem is when you have the superstar and the junior intern, 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 if he's that bad, if she's bad about whether or not our junior interns.
But you, know if somebody says 2 hours and somebody else says 20 hours.
How are they going come to agreement?
Right?
They can't, 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, and that's the benefit to points.
Absolutely agree.
Well then let's reframe it a little bit.
Let's refrain estimation.
If it's not really about prediction, what would you say it really is for?
What do we use estimation for.
To make the decisions that we've talked about, right?
You want to estimate so that you can make a decision.
Put a product backlog item and we call it three points.
And the product owner says, three point's 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 point.
And so that quick estimate on a product backlog item lets a team know, or lets the product owner know how much they want the thing,
right?
It's desirable, but not at that price, I'd like a Ferrari, not that at price.
So it helps us make those decisions.
We put a estimate, if we do it in sprint planning, we put an estimate in a sprint backlog, say a programmer says, eight hours and the tester says they'll
take 12 hours, the programmer might say, wow, 12 to test that, you know, is there anything I can do to make that easier for you to.
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 testing by 75%. So those estimates can help us make decisions.
Yeah, I agree.
And I think that's kind of the focus is on the purpose.
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 That's a great question.
And it's the subtle one.
This is where I will have arguments to people that are kind of opposed to estimating.
They'll say things like, oh, no, we don't estimate.
We 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 I mean, we're estimating all the time.
You know, you and I scheduled time to do this podcast recording.
I had a doctor appointment about a half hour away from me this morning before we started recording, I have to estimate how long would my doctor take?
How long it would take me to get home?
Things like that, right?
So we are estiming all of the times.
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.
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.
My response generally is, well, that's great.
I mean, if you can do, then I think there's value in being able to do.
That I can only speak from my experience.
haven't worked on a team where we've been able get everything to same.
There's just always some things that are bigger than others and we can't split those things further.
So that why for me, estimations better.
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.
But I'm with you, I'd rather have the thing where say, okay, everything's one to five, right?
If that's what we want to do, we wanna target things that are twos and threes, of course we have trivial things, let's call them one.
Of course, things are a tiny bit bigger, will come fives.
That'd be a better approach to me.
It'd faster, be faster.
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, you know, like it keeps you from being adaptable and it''s framed in that kind light of it being an obstacle to being adoptable.
Do you think that's actually true?
So 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 know, it, was Agil versus plan driven.
It was agile versus waterfall, what, do, we, call, the opposite and plan-driven was one of, that was discussed.
And I don't think we want to be plan, driven, I mean, when I'll be driven by the plan.
But I think a reasonable amount of planning, and again, it can easily be overdone, a reasonably amount planning improves our agility or our adaptability.
You 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 gonna face, right?
And the troubles that they are gonna have, the obstacles they gonna encounter.
And so they plan, they planned that the trip up the mountain might take longer than expected.
They plan by taking extra supplies that can use on the way down.
So that planning improves their agility and improves the ability to adapt to the condition.
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 things that this gives us in that kind planning is that if we kind can look ahead and see, well,
this is a potential issue.
Well, now we can have more possible avenues to solve that rather than when we're right up against it, there's maybe only one way to deal with it.
Absolutely.
Well, I know one of the other areas that, 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 flow metrics.
And I, know that that is a popular thing right now.
So I'm sure people are kind, of interested in your thought on that.
From a flow metric's perspective, what do you think it does well or what are you thinking it struggles with and falls short with as,
as a way of planning?
I 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 were doing something that's completely new.
There's extra complexity there and I dont think the flow metrics handle that as well.
um so having you know having kind of more traditional metrics having estimates and you're balancing them out right with the flow metrics is going to be
the way to go you this is the thing with any sort of metric or measurement you never want to rely on just one thing right think about you get on an airplane
you look up and see how many controls or gauges the pilot has like, holy cow, right?
You wouldn't want to fly a plane with one gauge, or you want.
Have multiple views of where you're at.
And so for metrics, you are a good supplement, but, um, I think they help ground conversation.
But I.
Estimating more traditional estimating helps us think through the challenges that we can anticipate with, with work, especially novel work.
Do you think these two kind of compliment each other flow metrics and, and estimating with some story points?
Yeah, I think they can be a good balance.
It's certainly useful to see how many items are flowing through our process, right?
But it's also good to what the sizes of those things are.
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 go a little bit deeper on.
Let's talk a bit about the human impact of this.
What do you think happens, Mike, to teams when their planning and estimation are kind of stripped away entirely?
Well, this is a little bit back where we started, where I was saying the developers kind to say, what's in it for me, right?
I estimate what is in for it me.
I gave the boss a number.
They're just going to beat me up with it.
There's no benefit.
We need to get to a point where developers understand that estimating well or planning well, even more importantly, planning can be beneficial,
mad to them, beneficial to.
Imagine a team.
That's just horrible at, at estimatin.
They're just horribly at estimated and planning.
And they're never right.
The business comes 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.
Well.
I think the business has every right in the world to say, give it a try.
Right?
Because 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.
Give it.
A try, Right.
And so in those organizations, we see businesses leaders putting a lot of pressure on the team to go do it anyway.
Go give, it try and 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 minutes.
You 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 are not perfectly, right?
But they were pretty good and they built up this track record of being pretty.
And now the business comes with that same new project and says, can we do it in three month?
And the teams says no.
Now the business is gonna listen, they're gonna say, oh, okay, it can't be done.
What would it take?
And here's the key thing.
what would 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 we have one more person, whatever it is, we'll have 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 could do in 3.5. And it's a collaborative discussion now.
Whereas before, when the team was bad at estimating our planning, it was just to dictate, make it so.
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.
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 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 better or worse at Well, absolutely, but it depends on why they're wrong.
So let's just talk about a few things there.
Um, so the most common thing when I hear that a team is bad at estimating and they are 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 were just complexity, right?
Points are not complexity.
Complexity is a factor in the effort that is appoint.
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.
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.
You know, they don't agree on what point it is, because that is the antithesis of a Point.
So I'd want make they had a very clear definition of, of point.
From teaching this for so many years, that's hard.
There's this magic point people have to get to with points.
And I see this when I'm teaching.
When they get it, it clicks, and all of a sudden, every single thing about estimating makes sense.
Everything makes 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 always have better splitting.
They're very linear skills.
Just keep getting better with those things with practice, estimating there's this.
Magic point, and you have.
The team members, ideally all of them, at least a majority of.
To that inflexion 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 unpackings entails is discussing the components of the work, right?
Oh, to do that big feature, we'd have to this and this, and that's right.
Don't necessarily write them down, but just talk about them and then go back and estimate the big things.
So don't estimate to small things, the unpacked refers to identifying those small thing.
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 are estimations.
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 worse case narrow, but kind like the 90% scenario.
Right?
You know, they were thinking about all sorts of things going wrong.
You might have somebody else on the team estimated most likely scenario what most like will be done in three days, 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 percent of it will 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 gonna have arguments.
So if your in with a time and you see them having big discrepancies in their story values, because of that.
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.
I can go on and on.
But I think I've got a video of about five things to do to get better and four things stop doing that'll get you better.
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 lots of the problems
come from, is just sort of a misunderstanding or misusing of story points.
I know for one, I always know that there's a misunderstand and misuse when I hear developers talking, about I want to get credit for the work from this sprint.
Uh, know there is a, a misunderstanding or a miss use of them.
If the misuse of these is so widespread, why do organizations keep asking for story points then?
Because they...
I mean, I don't know that organizations ask for a story point, organizations asked for plans, right?
You know, give me a date, when will you be done with this stuff?
And it's because, to a large extent, that's how organizations run.
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 train users on it.
We may need update website documentation about the new features, all sorts of things.
Having some sort of plan, it doesn't have to be very far into the future, some plan is extremely helpful.
Do you think estimation can become harmful in the organization and what kind of things would signal that it's kind it has taken on a harmful turn?
Well, that's when you're running around beating the team up with the five and the eight that I mentioned, right?
When estimates are used to punish developers, when exceeding an estimate is viewed as a bad thing, it's an estimated you are going to be over.
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 at more of like a 90% level.
But individual estimates, if we're doing them at a median, that means we are going to be off half the time, right?
If we were to do it well, we would be of half of the times.
And most teams would off a little bit more than that because they are not particularly good yet.
So we have to in some ways celebrate the fact that some of our estimates were over, what we want to have is a process where we some over some under and
they balance out, and that's where a lot of teams go astray.
So I think, you know, punishing people for high numbers, um, publishing teams for, uh, high variance in their work.
Um, 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 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 make it 16. And those are not good
and bad news.
They're just random statistical variants or variability.
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.
Oh, no, You were two points under.
You only got 18 done.
It's like, yeah, That's random variation.
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 mis-used and people come out of that, those situations and think,
oh, estimation itself is bad, but it's not really the estimation.
That's the way you're doing it.
Now that really ends up being the problem.
Yeah, there's just numbers.
It's all about how the numbers get used.
And that's normally a failure of leadership intent in how leaders are intended to use those numbers rather than of the estimates or the team themselves.
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 responsively.
Estimate responsably.
Maybe that's your show title this time.
Yeah.
I estimate responsivly.
What would you give as advice to estimate responsible?
We haven't talked about this, but I think one of the important things is to think about estimates as ranges, and think of plans as range.
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 are going to submit, depending on the weather when they get close to the summit.
So use a arrange.
If we say we're going finish something, we'll be done in two to three months or two and a half to 3 months, or we're going to be done in four to five sprints,
things like that.
Or we'll be down in 4 sprits, 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 going make a decision.
And I think it's very fair for team members to say, would ask for an estimate, very fare for a team member, say cool, we will do that,
by the way, how will this number be used?
Right?
Oh, I don't know.
I just need an estimate.
It's like, we're not estimating that.
So estimate if there's a reason.
Right.
And I do think that teams can get better at estimations.
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.
What are we assuming will go right?
If we're summiting Everest, I assume that we are going to have good weather one day during the third week that were on the mountain,
whatever.
So I have to think about things like that and use the estimates, the estimations 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 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 this sprint backlog.
And at the end of the meeting, I deleted all 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 number.
So I cared if we put the right amount of work in this print and those numbers were there to help us put them out and work.
There we go again.
They were about making a decision, right?
Those numbers helped us make a.
Do we have the right amount or not?
And I didn't want the numbers to remain because then people were going to feel like, Oh, no, I said four hours to code that thing and it's going take me five.
I'm going feel bad or I better rush and be sloppy.
So I knew that was kind of a propensity of that team.
Deleted the column.
Right?
I say, this isn't important anymore.
We got the benefit out of those numbers were done.
I love that.
I think that builds trust as well because of the reason you said you're not going to hold someone to five hours if they said five.
It takes what it takes and we just learn from it.
Yep.
Um, well, I know these, this is a, 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 inbox gets flooded with, you know, different opinions and hot, hot takes on these kinds of stuff.
And insults and all sorts of things.
Right.
Exactly.
Please be kind.
Everyone please just be, kind, right?
Uh there, it doesn't cost you anything to be.
Don't insult my mother.
You can insult me.
Right.
Right, but I think the thing I'd want to ask you, Mike, is, uh, as we kind of wrap up is if you could give a message to the,
those listening, the agile community in general on estimation, to help them kind better understand this or, or maybe set right something that's not really
correct on, on this.
What, what, would be your one message you'd people to take away and hear from this?
My one thing.
Yeah.
Your one.
Probably that estimating and planning don't eliminate uncertainty.
We're not estimations so that we can predict the future, we're estimators so we that can make decisions.
And when we estimate and talk about the uncertainty in items, in work, it allows us to navigate that uncertainty, allows to create plans to get around it,
right?
We can dock those assumptions, create a plan together to go around.
But we are not going to eliminate uncertainly and that's absolutely not what estimatting is about.
Yeah, I love that.
I loved distilling it down to just making decisions.
That's a great way to put it because there's 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.
Yep.
If it won't help you make a decision, don' estimate.
Yeah.
Absolutely.
Well, this has been great, Mike.
I really appreciate you coming on.
Now, again, everyone, you know, 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 onto the show again.
Thanks as always, Brian.