#noestimates | Are Estimates The Comfort Blanket of The Corporate World? Chat with Vasco Duarte

estimation are people's comfort blanket, right? It's the safety that they expect

right? It's the safety that they expect to get. It's it's almost like, okay,

to get. It's it's almost like, okay, let's guess what the weather will be like in 5 days. By the way, most weather forecast falls off a cliff in terms of accuracy after 5 days. That's one of the

core agile principles, right?

Simplicity, the art of maximizing the work not done. As I often say, code is a liability. But when we work from project

liability. But when we work from project management, we maximize the liability and minimize the visibility into what might be valuable. Many projects are

estimated before we even know who is going to work on them or what really will be needed to to be done. You know,

sometimes we just have like a oneliner, right? But after that, all bets are off.

right? But after that, all bets are off.

We don't know what's going to happen. I

mean it is 2025 April as we record this.

Uh just look what's happening in the world, right? Like there are companies

world, right? Like there are companies who don't know how much their products are going to cost tomorrow because there's someone in a very high position of power who can literally decide what

kind of tariffs to impose on the products that you produce. That's not

under our control, right? like we we can't and that's why agile is so valuable because it gives us the tools, the ability, the thinking models to live

with that level of uncertainty and still thrive. Hello everyone, welcome to

thrive. Hello everyone, welcome to another episode of the agile state of mind and I have with me Vashkar Dwarte who is a legend, an agile legend, let's face it. Hi there Maria. Hi there

face it. Hi there Maria. Hi there

everybody. It's a pleasure to be here.

Thank you for having me. Oh, I'm super happy. I'm stoked to have you here

happy. I'm stoked to have you here because today we have a great topic. But

before I will just shortly introduce you. Vasco Dwarte is a well-known figure

you. Vasco Dwarte is a well-known figure in agile and scrum and especially in the community, especially recognized for

hosting the Scrum Master Toolbox podcast. You can watch our episode that

podcast. You can watch our episode that just came out last week, the bonus episode. I really recommend you to see

episode. I really recommend you to see it, to watch it, to actually listen to it and we talk about the divide between

the leadership and the practitioners in agile. Very interesting stuff. But apart

agile. Very interesting stuff. But apart

from that, Vashko is a co-founder of Agile Finland, right? You live in Finland. And most importantly for

Finland. And most importantly for today's conversation, Vashko is the author of No Estimate. So he started the

movement that we now call # nostimates and and you know I was looking at that and Vashko has started

talking about it like 20 years ago is that right almost yeah 19 years ago was when I published the first uh blog post

challenging the value of estimates interesting so I I'm just very surprised Guys, how is it possible that you have

been talking about it for 19 years? How

moving away from traditional estimation technique in software development can actually benefit the teams and the stakeholders and the companies but we

somehow still keep estimating. Why do

you think that is? Yeah, I mean we were joking uh before the recording that uh estimation are people's comfort blanket, right? like it's it's the safety that

right? like it's it's the safety that they they expect to get. It's it's

almost like okay let's guess what the weather will be like in 5 days. Uh by

the way most weather forecast uh falls off a cliff in terms of accuracy after 5 days. So let's guess what uh the weather

days. So let's guess what uh the weather will be like in 5 days and then let's make huge investments based on that guess. Uh and the the cool thing about

guess. Uh and the the cool thing about the weather as an example is that the weather is out of our control and so is the execution of software projects,

right? Like one of the the core aspects

right? Like one of the the core aspects of project management which is the origin of this idea of estimation for software development. Although

software development. Although estimation in general is of course a much broader idea but when it comes to managing software development estimation comes straight from the ideas the the

theory the the practices from project management and project management expects that control is exerted by the observer the project manager right like the project manager controls the

development of the software now anyone who's worked more than a couple of weeks in a software development project knows that there's a there are a lot of things that are outside our control like when

are people going to be ill? Uh when is a an urgent all hands meeting going to be called? When is a critical server going

called? When is a critical server going to be down and the whole team stops to work on the problem until it's fixed?

Like all of those things are happening all the all of the time and are totally out of the control of the teams or the project managers. Yet the whole idea of

project managers. Yet the whole idea of estimates, the idea without which estimates make absolutely no sense is that we control what happens in the

future. Now sure of course we control

future. Now sure of course we control more or less what happens in you know 5 minutes, 5 hours, some would argue even 5 days but after that all bets are off.

We don't know what's going to happen. I

mean it is 2025 April as we record this.

Uh just look what's happening in the world, right? Like there are companies

world, right? Like there are companies who don't know how much their products are going to cost tomorrow because there's someone in a very high position of power who can literally decide what

kind of tariffs to impose on the products that you produce. That's not

under our control, right? like we we can't and that's why agile is so valuable because it gives us the tools, the ability, the thinking models to live

with that level of uncertainty and still thrive. And I think that we're going to

thrive. And I think that we're going to talk about this, I'm sure, in this conversation, but no estimates. It's

just the idea of taking agile uh concepts, practices, models, and turning them all the way up to 11. Turning up

the good, as Wood Israel likes to say.

Exactly. And I would like to just add that you know I used to think and as all many of us do with the kinfin framework

and thinking about okay we are in the complex right realm but there are also the simple one and the complicated one not to mention not to talk about the

chaotic one but even the simple on the complicated we would think that you could estimate like okay I can tell you you know it's not software develop

velopment. I can tell you when your

velopment. I can tell you when your bathroom will be done. And I really had just this super great experience of

having a renovation at my home. And I

can tell you for a fact that it's not such a big difference. It really it was supposed to take maybe a month. That was

like the longest. It took two months.

And I'm still not like over it. It's not

over yet. So I'm thinking we just wish we have this wishful thinking and I'm sometimes considering is it like the Einstein said like you know you keep on doing the same thing expecting a

different result and and you're you really believe one day the result will be different and that's basically what happens with the estimates. So I just don't I want to highlight that you know

we just had this big blackout in Portugal and in Spain nothing worked. So

go ahead and plan your life, right? And

then you you just face something so unpredictable, so unusual, you go ahead and then you have to like recover, right? It's not just one day, it's the

right? It's not just one day, it's the recovery afterwards. And so th this uh

recovery afterwards. And so th this uh kafin model is actually very useful reflection. So simple is a domain where

reflection. So simple is a domain where um basically cause and effect are understood. We can we we can know what

understood. We can we we can know what is going to happen in the in the sequence. In the complicated is where

sequence. In the complicated is where experts are the ones who know what's going to happen because it requires a lot of knowledge which is not available to the common population. Then complex

is where cause and effect are only visible in retrospect. This is very important. Only visible in retrospect

important. Only visible in retrospect meaning that only after something happened can we start talking about what might have caused it. Right? And there's

a lot of opacity. It's not transparent what what is the relationship between cause and effect. And then chaotic where cause and effect are actually unknowable, right? Like there's no way

unknowable, right? Like there's no way to know that. Now if you think about this idea cause and effect is a very basic principle that everyone who went

to school learned and we were taught since we were quite young learning maybe about the first things related to physics or the environment or or something like that that there's a

relationship between cause and effect.

Cause being something that happens before effect meaning the consequence of what happened before. Now estimates need that relationship to exist, right? So in

order for an estimate to even be theoretically useful, we need to know that the decisions we're making today when we're doing the planning will have an effect of causing things to happen in

the right sequence at the right time with the right people doing the right things in order for the estimates to be true. Everyone in software knows that

true. Everyone in software knows that this can never be the case.

And I mean just just anecdotal many projects are estimated before we even know who is going to work on them or what really will be needed to done to be

done. You know sometimes we just have

done. You know sometimes we just have like a oneliner right so it the the the the whole idea of cause and effect is at the basis of

the use of estimates. Right. It's it's a necessity for estimates to be even credible. We need to believe in cause

credible. We need to believe in cause and effect. And in software development,

and effect. And in software development, actually in most human endeavors, we know that the the uh uh relationship

between cause and effect is far from simple and most often it cannot be predicted in advance. And there's so many things that come together that

necessarily anyone planning a project is only considering a very small amount of possible causes.

Exactly. That's I I would like to show that as a because I have some charts from real teams. It's not that I you

know we can talk in in theory and we I I would really want to show how that is practical in what the teams do. But

before we go there, I would like to just say, okay, so you're talking about no estimate. What's the other I need as a

estimate. What's the other I need as a stakeholder, I need to know, you know, there is a budget. I need to uh have the other teams know or the board, the

stakeholders, they need to know that we can do something and they can expect some outcomes coming from the teams. So is there a different way or we just hate

on estimates because we don't believe very important question, right? Like uh

the people who are paying the money want to know what are they going to get from putting the money in. That's a a very important question. Now, here's the

important question. Now, here's the thing. For us to be able to answer that

thing. For us to be able to answer that question, we need to transform what is a business problem into a task, right?

Okay. We already lost the guidance. We

already lost the reason why we are doing the task because we may have had a stakeholder with a great business idea, an outcome that they want, right?

Something that they want to have as value for the business. But through the project management chain, we have transformed that outcome into very clear assignable tasks. So descriptions of

assignable tasks. So descriptions of things to do because those are the only things we can estimate, right? We

describe what needs to be done, work breakdown structure and then we estimate those tasks. We put them in a sequence

those tasks. We put them in a sequence and then we have a work breakdown structure that is estimated. Here's the

thing. When the stakeholders ask, "When am I going to get this done?" They're

asking, "When am I going to get 5% more user retention? When am I going to have

user retention? When am I going to have 10% more revenue?" But the project can't answer that question. We're using the wrong tools to answer our

stakeholders, right? like and and to to

stakeholders, right? like and and to to coming back to your original question, but the stakeholders want to know. Yes,

they want to know, but the tools we're using estimates and project management to answer them are answering a totally different question. The uh uh if I could

different question. The uh uh if I could make it in a in a simpler way, the stakeholder is asking when am I going to get 5% more user retention? And we're

saying we're going to deliver this features by March. There's no correlation with user

March. There's no correlation with user retention. We've already lost the game.

retention. We've already lost the game.

Lost in translation to estimates and that that is the problem. Estimates is

like the tail wagging the dog. Estimates just by existing remove

dog. Estimates just by existing remove the ability for us to work from a business perspective, from a value perspective.

That's an interesting perspective on it. But yet

somehow you know I I when I go and talk to the teams and we do this workshop of okay you know there is the way or that we do estimating everything over and

over again. But there is also another

over again. But there is also another way we can just see the throughput how much we do make some simulations use Monte Carlo and it will have inside all

the all the complexity and the randomness at least of your system. It

won't be perfect but it might get better. What happens? People feel that

better. What happens? People feel that they if they don't make this big job of trying

to analyze this oneliner they get for annual road map. They don't make the job. They don't ask the architects for

job. They don't ask the architects for for directions. They don't really spend

for directions. They don't really spend time on it. it won't be as as sufficient as efficient or as you know they won't

feel that they made an effort enough to present that estimate. So they do all this work which later they have to do again because half of that road map is

not going to happen but still they feel that oh this is too easy easy is not enough you know.

Yeah. No, I I I I I do get your point like using uh forecasting strategies like uh throughput for example or cycle time can feel that you know ah but it's

it's so unrelated because we don't even know what we're going to do. That's

true. Yeah. But when we do the analysis of a a major feature for example, we do the analysis, we say these things need to happen, these sub features or user stories need to be implemented. We're

spending quite a lot of time on that.

Then we're going to spend time justifying why we are not doing that because the plans have changed. Then

we're going to spend time trying to recover from the delay, which is natural because things always take longer than we thought they would take. That's

Parkinson's law, right? And we spend a lot of time having meetings justifying why we're late. And all of this time is because we started from the use of

estimates. That is not necessary. We

estimates. That is not necessary. We

don't need any estimate to know that our team will still be here three months from now assuming all things are okay and we'll be still working on the business goals that matter the most for

the business.

And that's what we need to start focusing on in software development. We

need to go away from financing work items to funding teams and the teams do the most they can with the time

available. And then the the priority of

available. And then the the priority of the things coming into the team becomes the most important task. The most

important task in software development is to figure out what should we do next given what we've learned so far. Right?

The product owner and product manager job is extremely important and that is completely independent from estimation.

In fact, it's the opposite because if we estimate, then we don't give the product manager and the product owner the ability to react to information that we are collecting throughout the

development. We get to stick to the plan

development. We get to stick to the plan which is the opposite of what we want to do. We want to respond to change, right?

do. We want to respond to change, right?

So all of these things come from just using estimates, just having that mindset that we must estimate. If we

remove that mindset, if we start using throughput or or or cycle time as you suggested, Maria, then we can go back to the original goal of software for a

business to deliver value and we can make decisions and we can adapt to the information we collect. We can talk to customers, get ideas, implement those.

We can be much more agile, responsive, adaptive than if we start from estimates.

So could you like quickly summarize what's the alternative because I understand that now everybody's heard estimates bring a lot of problems along

themselves. They actually create kind of

themselves. They actually create kind of a framework of misunderstanding. What do we do instead?

misunderstanding. What do we do instead?

Yeah. So uh I I think there are two phases here. The first one is to start

phases here. The first one is to start using something like uh throughput or cycle time and of course a incremental and iterative development of the

backlog. Right? So we we can still have

backlog. Right? So we we can still have those one year or even longer goals but we start directing our work towards those goals. We don't plan those goals

those goals. We don't plan those goals in detail into the future also because that would prevent us from discovering what might deliver those goals much faster and cheaper than implementing the

original plan because the original plan was developed when we knew the least about what needed to be done. So that's

step one, right? Like get rid of the idea that you need to plan everything and estimate everything in advance.

Start iterating towards a specific business goal. This is very important.

business goal. This is very important.

Start from the business goal. this is

what stakeholders care about. Then step

two is to start making uh to start transforming software development into much more of an investment problem than a project management problem. And and

here I want to be very specific.

Investment means we put a certain amount of time and money towards a goal. If we

get closer to the goal, we invest some more. If we get further away from the

more. If we get further away from the goal, we re-evaluate if we should continue to invest or invest in something else. So to be very clear, if

something else. So to be very clear, if our stakeholder says, "Hey, our company needs 5% more retention, we discuss with the customers, we discuss with product owners, product managers, we come up

with an a set of ideas using, for example, impact mapping on what could be a good strategy to get that increased retention. We develop part of it, not

retention. We develop part of it, not the whole thing. We develop part of it.

We get feedback from the market and from customers. Is it working? Yes. Okay. Now

customers. Is it working? Yes. Okay. Now

it's time to decide. Do we invest more or do we invest in something else? Maybe

we already got the 5% retention we wanted. Now maybe we can invest in

wanted. Now maybe we can invest in something else that is also needed. Like

for example, user acquisition, whatever that may be, right? Software developers

and and software engineers need to stop thinking that their role is to write code and they need to start thinking like product engineers. Our goal is to come up with engineering solutions that

deliver on customer value and business value. Writing code is a task. It's it's

value. Writing code is a task. It's it's

a tool. It's a medium, but it's not the goal. As I often say, code is a

goal. As I often say, code is a liability. But when we work from project

liability. But when we work from project management, we maximize the liability and minimize the visibility into what might be valuable. We want to stop that

and we want to start using this investment metaphor, right? We invest a certain amount of time and money into a direction like user retention. If it

works, we invest some more. If it

doesn't, we re-evaluate just like we do in the stock market.

I love that. Could you repeat the what you said about liability? I think it's really interesting. Yeah. If if we use

really interesting. Yeah. If if we use project management as the way to manage software, what we do typically is that we break down a goal into tasks and

those tasks are then designed, right?

Like changes to the architecture, user stories, whatever that is a recipe for maximizing the amount of code changes to reach the goal. How do we minimize?

Because that's one of the core agile principles, right? Simplicity, the art

principles, right? Simplicity, the art of maximizing the work not done, right?

So how do we do that? Well, we run experiments not necessarily with code. I

just wrote a uh recently on Substack a post about that. We need to validate features before writing code, right? So

we validate, we use this uh uh lean startup cycle, build, measure, learn. We

validate features before we write the code. And then if the features are uh

code. And then if the features are uh proven to be valuable, we write that code of course. But we don't start by maximizing the amount of code we write to reach a goal. We do the opposite. We

start by validating does this work. We

do paper prototypes, clickable prototypes, landing page experiments, user interviews, whatever it takes to validate if an idea actually delivers

the value we want. And that's how we minimize the code because code is a liability. The more code you have, the

liability. The more code you have, the more you need to invest just to maintain that code.

Yeah. And now I think I get why we keep on estimating and making plans because it's easier. Why would you bother to do

it's easier. Why would you bother to do all the things you just said if you can just plan something and then like are

you meeting my plan? You know, isn't that easier? I I don't I don't know if

that easier? I I don't I don't know if it is easier, but it's definitely something we're used to. We learn in school and also Exactly. And this is something a developer once told me. So

because for me as a as a an old developer, I'm not a developer anymore.

Uh but I used to be a developer. Uh as

an old developer, it was always very uh obvious that that estimation was a waste of time. Like why why would I I I know

of time. Like why why would I I I know what to do. I'll just go and do it, right? But then I talked to a developer

right? But then I talked to a developer who once uh uh cleared it up for me. And

the developer said, "No, we love Estimat." So I like, "Oh, that's

Estimat." So I like, "Oh, that's surprising. tell me a bit more like what

surprising. tell me a bit more like what what's behind that and he said if I give my manager uh an estimate I say oh it takes two weeks they'll go away and I

can work for two week two two weeks in peace and nobody bothers me and then I asked which is the obvious question but what if it doesn't take two weeks I mean you know at the end of the two weeks it

might take a lot more and then the developer said well then I'll just tell him two more weeks So easy. But you know, I really think about

easy. But you know, I really think about that a lot about how if you go to the university, at least where I was, it was always this this lecturer, you know, the

person that was just reading or sometimes even remembering what they need to say because they used to say the same thing forever and ever, right? for

25 years they say the same thing to the same students expecting like people to sleep in their in their benches and why don't we do like we say in agile there

are so many great ways to conduct a workshop to use the learning from the back of the room right that people learn by discovering you know so many

interesting concepts I don't remember because they were sold in a way that I didn't care and this is the same thing like the professor They think, "Oh, I had to learn so much

to get here. Now I will just repeat the same thing over and over again." And

that's the same here. We repeat the planning over and over again because later we can just release it and wait and just say, "Are you meeting my plan?

Are you meeting my deadline? Is it?" And

you know, you don't have to do anything.

You just ask the uncomfortable question.

Absolutely. Right. There there's another part which is uh something I've been saying for quite a while which is that estimates are also the reversal of blame right like it is the business

stakeholders who need to decide how much we invest in something but as long as we got an estimate now it's the developers and the engineering department's fault

for not delivering on the plan exactly and I what I tell everybody is like this if your stakeholders ask you to deliver

on something that is described as value. You don't need to uh to have a a

value. You don't need to uh to have a a detailed plan of all the tasks that you need to do. Of course, you need to have an idea, right? Like, okay, how do we

increase um uh retention? Well, we

request feedback from product managers, sales engineers, salespeople. We come up with a few possible obstacles. We score

them somehow. for example, the ones that are most referred, most talked about, and you say we're going to solve this problem here, but we're we're saying we're going to solve this problem. We're

not saying we're going to do all of these user stories. And that changes the conversation because now you're helping the stakeholder get what they want.

You're not giving them a set of tasks.

You're helping them get what they want.

And now they want to be part of the discussion, right? Like, okay, so let's

discussion, right? Like, okay, so let's do a few tests. let's or a few experiments. Let's see if we are indeed

experiments. Let's see if we are indeed solving those problems which we identify as potentially causing lack or or lower retention. That is interesting for the

retention. That is interesting for the stakeholders. It's interesting for the

stakeholders. It's interesting for the customers and it's interesting for not for us as product engineers. And I think that this is the mindset that is right now missing because we have built this

infrastructure of project management where the goal is to detail the tasks and the people doing the work are so detached from the goals that they have no reason to worry about anything else

other than giving estimates and just doing their work. And because we're always late, I mean the success rate of projects is is ridiculously low. because

we're always late. If if a a a team or a a a department says, "Oh, yeah, we're late with this delivery." Nobody bats an

eye. It's like is it it is as if it was

eye. It's like is it it is as if it was expected. I'd say no uh estimation is a

expected. I'd say no uh estimation is a financial disaster because imagine and we know this from agile. Imagine if you could deliver the same value, not the

same functionality, but the same value with onetenth of the money. In some cases, it's possible.

money. In some cases, it's possible.

It's not all impossible in all of the cases, but in some cases, it's possible.

And that is a win. Why aren't we looking at these wins? Because we use estimates.

And the moment we write the tasks down, it doesn't matter that we could deliver it with less work. We need to deliver all the work we wrote down.

Yeah. Yeah. Because also it's like we we um it's as if we told you to do this, we expect this outcome and we never see in

the middle if that actually is enough or not. If we actually change direction no

not. If we actually change direction no I just let me know when it's done right and then it never comes and then there is a lot of frustration and I

think it really I sometimes feel that we are only talking about these deadlines nobody cares anymore what we are delivering we are not talking about the value we are only talking about why the

deadline hasn't been met again this is not a problem this is not and yet still we are there and Now I would like if you

if you don't mind show a few charts that I took from the teams because I was like okay but we are talking a lot how do I

even start the conversation if if we don't understand why there is a problem in the first place right because we are used to everybody everybody estimates we

should just estimate let me just find yeah this this slideshow So this is what I actually took from a

team and this is the same this is the same team and a different sprint and an interesting thing here is we see issue

story points. So the story points that

story points. So the story points that they put to the to the user stories and works uh work days in a transition status. So basically the work days that

status. So basically the work days that it took uh it was uh it the statuses were all the things that we consider work in progress right from to-d do till

it has been done and it's amazing. It's like we really spend so much time estimating to see this to see that three story points

can take from less than one day to 14 days that there's even one next to 26.

All right. Yeah, it can be. Could we use and if you if you just look at the data like if you squint your eyes and just look at the area that the dots uh

occupy, you can say that one and two story points are definitely smaller than the others. But you can't say that three

the others. But you can't say that three and five are any different because the data is so scattered. But also in most cases, one, two, and three are the exact

same size because there's only about three dots on the line on the three points line that go beyond what the two

goes. And th this is, by the way, it's

goes. And th this is, by the way, it's really lovely data that I have seen over and over and over again, right? Like

this data is everywhere. If you look at it, you will find it. uh and and this just shows that the estimation did not

contribute much information to the actual size of the work to be done.

Right? In fact, we could argue that if we just look at this point, only the story line only the three story points line has some information. But that

information is so rare because it's only three dots out of all of the dots. Yeah.

That actually it could be just a random thing like a vacation period or or a longer weekend or somebody was sick or

whatever, right? So the data is already

whatever, right? So the data is already telling us that literally one, two, and three. For number five, we don't have

three. For number five, we don't have enough data, but for one, two, and three, we could say they're all about the same size. Yeah. Yeah. And then I also see, you know, interesting thing

that I saw. Uh this is the same team on a different sprint. And as you see here, three can be anything.

uh one well there was one one but what I also saw was that there was some rejection when you start scratching and like why is it that we have such strange

estimates as well like 0.5 one so many of them and I was told that there is some rejection from the

stakeholders to receive big estimates you know they don't want big estimates so we created okay this is 0.5 this is one and then when you look at it

it's like I remember it I think it was this team when I was looking at something that had three points you know three points in my head it's like half a week maybe they will be done for sure in

a week and it had like 28 days in progress then I saw something and and you can see here like 50 days in progress right and I'm like why is it

such a small estimate then there's a a three story point story that took more than a 100 days.

Exactly. And it's there. It's there in progress forever. Nobody cares. So this

progress forever. Nobody cares. So this

is so interesting that I understood that they are not really allowed to add many story points because then they are the

the the the most uh the the worst team, you know, like oh your team has such high estimates. So everybody has small

high estimates. So everybody has small estimates. Why do we even have them?

estimates. Why do we even have them?

Like, does it make sense? This is

actually a good point. So, a long time ago, I did a I talked to somebody who used to work at uh um at Microsoft, Bill Hanley, who did an experiment. They had

data for a very long project. It was

like eight months, nine months project.

And uh they they took all of the stories and they were at some point, let's say midway through, they took all of the stories and they just magically replaced

the actual story point estimates that they had for the stories with one. Mhm.

Right. So like, you know, there was one, three, five, eight, whatever, and they just magically replace, you know, uh search and replace changed all of the uh

story sizes to one. The difference

between the forecast of having everything at one or having the exact story points they had estimated was something like 8%. 8% to give you an idea, an 8%

8%. 8% to give you an idea, an 8% deviation between those two is less than half what a good estimation is supposed

to have as an error because a good estimation can be off by 25% in 75% of the cases. That's not my definition.

the cases. That's not my definition.

It's in um the the dark art of estimation by Steve McConnell. And this

is the point. When you just look at that data that you shared uh a moment ago, you could have replaced all of those different stories with just one. It

would add very little. It would remove very little information because we see that the outliers exist. Yeah. But

everything else, the mass of stories, they are all in that range of days.

Whether it's a one, a two, a three, a five, they're all in that range of days, right? And this is something I

right? And this is something I discovered a long time ago, which is that if you just count the stories per sprint and you use that as a forecast because it's so easy, right? because you

have the stories in the backlog, you have your uh throughput, so stories completed per sprint, you just burn down into the future from the amount of stories in the backlog and you got your

release date. I call this the Disneyland

release date. I call this the Disneyland huristic, right? Like imagine you're 800

huristic, right? Like imagine you're 800 kilometers from Disneyland. You drive at about 100 kilometers an hour on average.

You'll get to Disneyland in about 8 hours. You know, you might stop or

hours. You know, you might stop or whatever, but other than that, eight hours, that's where you go. That's how

we can do it for the backlog as well. If

we deliver between three and five stories and there's 30 stories in the the backlog, it's going to take 10

sprints or less to deliver. Exactly. So

there are so many ways that we can do we can use and we we also call it flowmetrics in in canon right and we can just and and we can use this

probabilistic way of simulating and also checking not the averages maybe we can come back to that but like the the percentage that we are comfortable with

let's say 85% of our sprints contain 10 stories or less. So we do 10

stories per sprint or less and that's what we can predict, right? But there is one thing interesting for me because I

saw this and I was like what do we see here? This is the reality of many many

here? This is the reality of many many teams especially if you work in a big enterprise. What we see here is it's in

enterprise. What we see here is it's in averages but you can see in the light blue you have average work days in transition status in progress. So we

have different statuses in Jira right in in our workflow. We have in progress, we have ready for release, we have in review and this team had on

hold and I actually it's the first time I love that somebody had on hold because I can this is the randomness of our

system. So you can even say that when

system. So you can even say that when they work when it's active it's actually quite predictable. You could say well it

quite predictable. You could say well it will take let's say I think here it's the days right so it takes let's say 6

days or less to complete what we have in a sprint to complete those stories what happens is that we have such a big randomness in our we which even when you

think about it okay we estimate really well you cannot say we don't estimate well because if I say I will do it in four days I might do it in three or Five. Great. I'm happy for you. What

Five. Great. I'm happy for you. What

about the on hall? What about when you are waiting for somebody, right? This is

really this is a a a really great illustration. So, I have an example. Uh

illustration. So, I have an example. Uh

in in the conferences where I go, I always ask people uh how old was the oldest item you've removed from your backlog? You know, and some people say 6

backlog? You know, and some people say 6 months, 12 months, whatever. The highest

I've gone is 10 years. So there have been items on hold, so in the backlog waiting to be picked up for 10 years.

Imagine that somebody had estimated that to two weeks. The product owner comes back 10 years later. Hey, you said it would take two weeks.

Yeah.

And that number especially there on the third bar where it's clearly it's what four times higher than the actual duration of work. This is the reality of

work that goes through multiple stations or through multiple people is that it spends most of the time on

hold. But guess what? You never estimate

hold. But guess what? You never estimate how long something will be on hold.

Exactly. That's impossible to estimate.

Which also means estimates are useless because the most important piece of information is never estimated. And especially you know given

estimated. And especially you know given that I can imagine there are teams that are really crossunctional and they can work end to end they I would imagine

those teams don't have such a big randomness because they are self-sufficient and they can finish something many companies don't have that

teams rely on other teams and once you have dependencies and not only one team it's like many many dependencies on any on many other teams and this is what

happens. So the more and that's why we

happens. So the more and that's why we also preach and we also talk about having transfactional teams and how much faster you would go if you could remove

and actually you know I usually when I see an on hold column I'm like why do you have an on hold it's like a trash bin a black hole but here it is so

interesting to see how much time something gets blocked and I would love for this team to come and Okay, why on a retrospective like what happened here?

Is there something we can actually do about this randomness? Is there

something that we can can we bring person from the team that we usually have most dependencies with, right? And

have that team member in our team so we don't have to stop and wait. There are

so many ways to to tackle that. But then

when I saw this, it's like I don't have to say anything else. If you want to go back and and keep estimating your stuff, it's your call.

Yeah. And of course there is I I mean I have my sympathy for the teams who end up estimating. They are not the ones to

up estimating. They are not the ones to blame and neither are the stakeholders.

It's just that the infrastructure for managing software development that we have in place today which is project management by the way is inadequate for

the reality of software development. We

already have better ideas like uh agile software development something like scrum or conbon or safe safe is better than project management. No matter how

may uh how many may dislike it it's still better than project management.

We just need to start embracing the already existing and well-defined infrastructure for software development.

And of course that requires some changes in decision making. So for example when we approve something to be done at portfolio level we don't do it once or

twice a year. We must do that as a regular function of managing software development. So we talk about product

development. So we talk about product owners uh deciding what goes into the next sprint, right? Like when you do the sprint planning, we're kind of prioritizing things and putting it into the next sprint. We need that at the

company level. The company should have a

company level. The company should have a function, a product portfolio function which is uh continuously evaluating the needs from the market, the needs from

the customer, the actual progress from the teams and deciding what goes into the next sprints. Now safe already has an infrastructure for that. It's called

the uh program increment planning. Uh

it's not very hard to implement something like that in a relatively small company with let's say five to 10 teams. If you have more than that, maybe you need something else. But within five

to 10 teams, you can easily have a group of product owners that comes together let's say every week or every two weeks and plans the next say four six weeks

for the teams. It's not impossible to do this. It's within the possibility. And

this. It's within the possibility. And

when making these decisions, they are consulted by the people who have the investment decision in in uh in hand and decide whether they keep on investing in a certain delivery or they switch

investment to another thing that has proven to be more important. It's not

impossible to do this. This is why I'm continuously talking about no estimates, but also its portfolio cousin, which is let's think about software as an

investment, not a project. We invest in certain software deliveries because we expect that it it will have a value in return. If we don't see any evidence of

return. If we don't see any evidence of that value coming back to us, turn the in investment off in those areas. Put

some more investment in other areas.

Exactly. I agree. I But I also know the reality and how this PI planning can go

really awkwardly bad.

But you know uh because we if you don't it is all about the mindset and seeing through and and checking like do we really it does it make sense like again

and again making this plan that's so detailed and especially bothering all the team because here we are talking about and the previous episode where I

was talking with Benji we were talking about about flow metrics and how we can leverage leverage it and how we can plan and I still have pending the episode

about uh Monte Carlo simulations because that's how this project manager and what you're saying people on this portfolio level could just look at the past and

say okay usually if we if we try to right size somehow our epics we have let's say 10 stories or less in all our epics oh sometimes there will be 12

sometimes there will be eight it's okay but not like 25 and five and then if we really look back it took this time to do

this many epics and then we they can plan this plan right make a plan for three months without even talking to the team they could right maybe there will

be some new technology it's good to talk and ask like do you know we have this new thing maybe we shouldn't even put it in a plan because we don't have enough

knowledge or we need to, you know, start creating something. But I think uh when

creating something. But I think uh when I was talking about it on my LinkedIn and I was like, "Oh my god, I need to share it and see what people say and how they solve those problems." I find out

that what really could use aside from all the frameworks is like a three-level planning. So we have some intentions for a year. Everybody

likes to know something might happen or not. We put intentions and and you

not. We put intentions and and you mentioned it. It's like those goals,

mentioned it. It's like those goals, right? Oh, we have this goal, that goal.

right? Oh, we have this goal, that goal.

This is what we would like to achieve in this year. Okay, great. We will not

this year. Okay, great. We will not estimate it for you. We you can ballpark it as you want, but please don't go to the team and and ask them for the

estimates and for the analysis of oneliners, you know. Okay. Then we have what you say it's it could be a PI planning. It could be some planning for

planning. It could be some planning for a quarter where we know more and we go to this epic level and say okay we have

this plan this could work right this is our high level plan estimation ballpark for those epics they can fit in this

three months and then you have the commitment for a sprint or for whatever iteration you work with and I think this

could be so much more refreshing if we actually call it differently at each level and and understand that this is an ongoing exercise and not just we do it

once and then we wait what happens right yeah absolutely and and I think that your point about these three different layers is very important uh it also fits

very well with the natural naturally occurring time horizons right so you have a year then you have a quarter Then you have a week or two weeks. And this

is very important because at different levels we're making different kinds of decisions. And what we don't want is for

decisions. And what we don't want is for somebody planning the whole year in October of this year to plan next year to make decisions that people will need

to follow at the weekly level six months from now. That makes no sense. But this

from now. That makes no sense. But this

is how we plan today. In fact, this is how project management requires us to plan today because you then need to break down those goals into what they call budgets. And in order to budget

call budgets. And in order to budget something, you need to decide what needs to be done too early because we we will only know when we start, but we're already deciding now. So, we're we're

kind of with the project planning approach to the yearly planning. We're

actually compressing a whole year of planning that could happen on a cadence.

We're compressing that to a couple of weeks where everybody's busy in a hurry to try to get all the plans together so that they are budgeted. So I would invite everybody to read into beyond

budgeting and how they talk about the need to move from yearly budgets to uh rolling wave budgets. And rolling wave budgets are great because they are one step closer to what I'm talking about

which is this investment mindset. An

investor does not say I'm going to put this amount of money in this stocks or this investments exactly at this time and I'm going to take it out at that time. Nobody thinks like that in

time. Nobody thinks like that in investment. They have a portfolio, a

investment. They have a portfolio, a bunch of money. Then they invest that given the risk they want to take in certain things, some higher risk, some

lower risk. And then g uh based on how

lower risk. And then g uh based on how the market develops, they might put some more money in, they might take some money out. They're constantly adjusting

money out. They're constantly adjusting their investment. They still have yearly

their investment. They still have yearly goals, but they're adapting every day.

So, let's use that. Let's use that that that those insights, that knowledge, that experience because the investment mindset helps us to manage risk in a much more effective, concrete, and

pragmatic way than any project management can ever do. I mean, think about this. So, I'm looking at a chart.

about this. So, I'm looking at a chart.

This is in how big things get done by bent fluieri and he has this chart which is the iron law of project management and it has three bars. The first bar is

all projects on his database. He has

tens of thousands of projects on the database. That's 100% all projects.

database. That's 100% all projects.

Okay. Projects on budget 47.9%. That's less than 50% on budget.

47.9%. That's less than 50% on budget.

If you add to on budget also being on time, that goes to 8%.

8.5%. Right? So that's already 91.5% of projects are not on time and on budget. And then if you consider all

budget. And then if you consider all three which is on time, on budget and on value it's 0.5%. The project management

0.5%. The project management infrastructure is bankrupt. It does not work. We need to find an alternative.

work. We need to find an alternative.

And the alternative I'm talking about is let's manage software as an investment.

We put some money in, we check what we what we get out, and then we decide whether we put some more or we stop doing that and move the money somewhere else.

Makes sense. I I think it's a great closing words because we made a loop and we came back to the money where which is

the the where we come from, where we start, right? We have a budget. We have

start, right? We have a budget. We have

some investment that we want to make and this is how we close the loop. So very

interesting and thank you for taking the time. I think it will be very valuable

time. I think it will be very valuable for the audience. I love to see the comments and how people react especially when you see you know that like I would

invite everyone to do the same just a simple you know even Jira has this dashboard. It's like you know if Jira

dashboard. It's like you know if Jira has this dashboard it's very easy. So

you can check it on your own. Take a few of your sprints, check how your estimates relate to the time. And I love it when I tell it to the teams and they

say, "Oh, we don't estimate in time."

And I'm like, "Great. What can I tell you? I'm I'm

"Great. What can I tell you? I'm I'm

happy you don't estimate in time and it works for you." So in the end, we need to estimate in time. So I would invite everyone to do this exercise and see for

yourselves and then decide do you want to go what you want to do with your time at work because you can probably do much better and more valuable things than

estimates.

Absolutely. Let's find better.

Exactly. Let's stop wasting time. That's

already such a big win, right? Thank you so much. Lovely to see

right? Thank you so much. Lovely to see you again. And and just last but not

you again. And and just last but not least, I I think we would invite everyone for the agile summit that's coming. Global Agilesummit.com. So check

coming. Global Agilesummit.com. So check

it out everybody. It's going to happen in May. This is where the best agile

in May. This is where the best agile thinking is happening today. Exactly.

And it will be in Talin, which I think is a great opportunity to also visit the city. Very beautiful. So thanks. Thank

city. Very beautiful. So thanks. Thank

you again. Bye-bye.

[Music] Hey down.

[Music]