Ep. 134: Estimation

In this episode, Peter Maddison and David Sharrock discuss the complexities and misconceptions surrounding estimation in software development and agile project management. They explore the differences between bottom-up and top-down estimation approaches, emphasizing the importance of continuous conversations and feedback loops throughout the process.

This week's takeaways:

• Bottom-up estimation, where every task is estimated and summed up, is highly inefficient and inaccurate, especially for long-term projects or when requirements are likely to change.
• Top-down estimation, which involves breaking down work into relatable chunks and understanding the journey, is more effective and allows for adaptability as the project progresses.
• Estimation should be an ongoing conversation between teams, stakeholders, and decision-makers, focusing on problem-solving, progress tracking, and continuous feedback rather than rigid timelines.

Tune in for a riveting discussion that challenges traditional notches around estimation in agile software development. Subscribe to absorb invaluable insights on nurturing continuous conversations, embracing top-down estimation techniques, and fostering an environment primed for delivery excellence at scale.

Chapters

• 0:04 Understanding Estimation in Agile Delivery
• 11:43 Breaking Dependencies for Effective Delivery
• 19:04 Estimation in Agile Development

Transcript

Peter: 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale.

Dave: 0:13

Peter this is a good chance for us to catch up. I gather we're going to have an interesting conversation today.

Peter: 0:19

Yes, let's talk about estimation, everybody's favorite. Let's talk about estimation Everybody's favorite.

Peter: 0:25

Yes, yes, this is a fun topic. There's all of the different sides, and one of the problems and I think we were just touching on it before we sort of dove into this today is that people think of estimation as different things. It has different meanings to people as to what is it. What is estimation? Why do I need to estimate things? When don't I want to estimate things? Why do I need to estimate things when don't I want to estimate things All the way through, from no estimations under any circumstances, all the way through to. Well, I don't know every single detail of the thing that's going to be done three years from now. And we could probably start there and say we both agree that estimating stuff that you've got no idea whether or not it's ever going to be done is a complete and utter waste of time. So I'll probably start with that yeah, I think there's ever going to be done is a complete and utter waste of time.

Dave: 1:05

So I'll probably start with that. Yeah, I think there's a couple of. Even there there's some assumptions, right? You're assuming we're using technology, we're building something in software or whatever it might be, because if you were building a hospital, you would probably want to have some pretty decent detailed understanding of what you're going to build, and that would be a couple of years out.

Peter: 1:29

Right, well, you're going to build and that would be a couple of years out. Right, well, you're going to have some targets. Right, you're going to have some things that you're aiming for, some things that have to be delivered as a part of that, and those are going to have dependencies that have to have occurred before them. So, for example, if, um, we we need to be able to provide oxygen into every room within the hospital, we would need to ensure that we've got some method of distributing that, and it would have to be built into the hospital and into the walls where you put all the walls on, and anybody who's built anything in their lives would realize that there are a sequence of things that have to occur. So there is definitely a need to understand what some of those pieces are because of the dependencies are because of the dependencies.

Dave: 2:03

Well, so and I think this brings us to a really important distinction around estimation, which is the estimation that we are talking about and we've been around lean and agile teams and software development and agile delivery of some form, devops, whatever it might be is we're making a huge assumption, which is we're working in a complex space where things can change all the time. So the value of estimating everything up front is near zero, because the reality is, as you move towards a target, whatever that might be, you're going to uncover things. Things will change. You've got to rethink what it is. You have to do so. Anytime you've spent estimating beyond the point that you rethink things is a waste of time.

Peter: 2:44

Right, exactly, and there's something that we see organizations all the time do is that they estimate out into the future, two years out, for a software project where you've got no idea if the thing that you're about to build now is even what your customer wants, let alone the thing that you might think about maybe possibly building two years from now customer wants, let alone the thing that you might think about maybe possibly building two years from now. In fact, technology will have moved on so much by that point that you can almost guarantee that whatever that thing is you're thinking of right now is irrelevant there. So it's not.

Dave: 3:13

Well, and I really I think this is something that we, when we're talking about estimation, one of the first things is why are you estimating? What problem are you trying to solve? Because, yes, everybody wants to figure out exactly what something will be over, say, 12 months, six months, a year, 18 months, whatever it is, and so they look for this detailed specification and estimation because it makes them feel comfortable. They've got everything mapped out.

Dave: 3:39

The problem is that there's low value in it because as soon as it changes, everything changes ahead of it. And it's a little bit like I actually do an exercise in a lot of workshops of this, where we plan to drive across North America, east to west, west to east, whatever it is, and you can have a plan. We all understand that that plan is going to morph and change depending on you know what places we want to see construction problems, how well we get on with the people who are driving with us in the car and all of these other things that come together. You can still have a plan, you can still have a timeline, but you do a low level of estimation in detail because it just doesn't make any sense.

Peter: 4:19

Right. And so there's estimation, which consists of the bottom-up estimation, where we try and work out what is every single task that needs to happen here. And then, if I understand every single task and I measure all those, I add them all up, which would be if I'm driving across the magnet and think about every single stop, all of these different pieces, and I'm going to add them all up together and that's going to tell me exactly how long it's going to take, which is highly inefficient and inaccurate and takes a very, very long time to do, but unfortunately, this is a way a lot of organizations do.

Dave: 4:49

Yes, yeah.

Peter: 4:52

And the other way of doing estimation, which is highly inaccurate too, but is the top-down estimation, and so there are ways of going about doing that, which we could start to talk a bit about, what the different ways of doing top-down estimation in a more effective way are. But I think, moving away from this bottom-up, we can possibly guess what all the different factors are.

Dave: 5:13

To add something up is a good first point, I think yeah well, and I think this thing comes to the question of is estimation required, for example, to give a date roughly when you'll get across North America? If you're driving east to west coast to coast, you know roughly how many days it is. If you're going to meet friends, what day do you say you're going to be available to meet them on the other side of the country for a dinner or whatever it is? And how do you make those long-term projections? And in the world of software delivery, obviously this is you know, if we've got a trade show in September of this year, what functionality am I going to have available at that trade show or whatever it might be? I've got a fixed time contract where I have to do a fixed amount of work. Am I going to be able to do that, given where the team is at?

Dave: 6:01

And the wrong way of doing it is this detailed breakdown and estimation of every single step. The right way is to understand that journey that you're on and break it down into sort of relatable chunks that make sense to look at. So from a driving across the country you might look at, well, roughly, how many miles can you expect to do day by day? Maybe you're going to look at that to say you know there is a difference between driving through mountains or driving on the East Coast versus driving on the West Coast because of population density and so on. So maybe you'll have some subtle variations based on geography or demographics or whatever it is. But broadly speaking, you know how many miles you've got to go. You're looking at averaging whatever. It might be 300 miles a day.

Peter: 6:41

You can come up with a plan which is not not terrible yeah, this, in math this type of problem is called a fermi problem, but anyway, we could always get into that. But the this, this, the, the logical way that we we break down and think about problems and exactly as you say, like how many miles do I think I'd be able to do on a day, and then I can sort of work out, given how many miles it is, how long it probably would, would take me. So estimation, that's what I would call, like that top-down estimation, thinking of what are the different, what are the chances that something would be, what's my level of uncertainty. And the further out into time I go, the more uncertain I will be about when is it going to happen?

Dave: 7:20

I might add something there, because I think the mileage and only doing it on mileage is a problem, a problematic. And the reason I say that is if I'm trying to drive east or west, or west or east, and all the miles I'm doing are north to south, I'm never going to get to the end goal. So I think this is where, when we talk about increments and incremental delivery, the increments is not how many miles am I driving, what's the velocity we're delivering per sprint, or whatever it is. The increments is what's the first city I'm going to hit, what's the next city and what's the next city, so that I can track progress as well as measuring progress, if that makes sense.

Peter: 7:58

Yeah, and when we talk about OKRs, and when we talk about OKRs versus KPIs, I mean this is the measuring progress, the objective and the key results that tell us did we get to that city? We know we got to Chicago because we had some good pizza, exactly, and I think this is well.

Dave: 8:13

Well, this is something that gets misunderstood. Um, because we're we're spending a lot of time working with, you know, major rolls out of applications and they talk about the components and when each component will be delivered. And that's a little bit like saying you know, we've done a certain number of miles, we've done a lot of work. That's valuable, but until you kind of drill everything to a point by saying we have now reached Memphis, you don't know whether all of that work was working the right direction, doing what you need it to do.

Dave: 8:43

So having it actually collapse into this is exactly where we are, and that's moving away from thinking about components, moving away from thinking about you know, I've got the database set up and horizontal layers in your systems and it's beginning to think in terms of incremental layers of functionality that I'm thinking about. You know, I've got the database set up and horizontal layers in your systems and it's beginning to think in terms of incremental layers of functionality that I'm building. I can now solve a particular customer problem. I can now solve the next tier of customer problem, whatever it might be to measure that progress.

Peter: 9:07

Yeah, it's delivering incremental pieces of value to the customer. It has to be functional. It has to work. What have we delivered that's actually going to be usable? Because otherwise we can't learn whether we were going in the right direction. Maybe we ended up in completely the wrong direction, absolutely. For example, where we're heading from Toronto to Vancouver, we end up in Halifax, hypothetically, hypothetically.

Dave: 9:31

Now, so all of that. I mean it is an estimation, but I see that much more about roadmap planning and it's long-term thinking and you know it's a very top-down, very much looking at mapping something out so that we've done our due diligence, we know where things would go right, whereas when I think of estimation, I think of a delivery team using planning poker and talking about whatever it might be or whatever estimation method you're using. That's a totally different problem that we're solving at that point.

Peter: 10:05

Well, yes, and I think of that more from a prioritization perspective too, or like an understanding versus the. So I mean, and part of the reason we estimate a lot of the time is so that we can prioritize, because we want to know what is the smallest highest value item. Yeah, yeah, so and how do we know that it's small?

Dave: 10:19

well, we estimate its size, yeah and I would add there's another huge. So so my product owner, my, my business, my, you know, whoever is kind of deciding what gets done first, second, second, third, they need some understanding of cost, of the estimation that comes in, and I think the other side of it is the delivery team needs to understand what on earth they are building, and the most valuable conversations around estimation I've seen is where you've got full engagement with the development team arguing backwards and forwards and quibbling a little bit about how exactly they would solve it versus how somebody else on the team would solve it, and understanding what is going to change and how they're going to be changing the system to deliver whatever it is they've been asked to deliver yeah, exactly, and so it has to be that collaborative conversation between the people who are understanding the, the, the why and the what and the people who understand the how and the when they like the delivery teams and the uh and the.

Peter: 11:17

I I put it into kind of that release management as kind of the people like, the people who understand. Well, when do we actually have to get that out? How are we going to learn that? What are the? What are the technical capabilities we might have to put into place to drive that as well?

Dave: 11:29

so, given given that definition, peter, I assume you have no problem at all with people estimating in days and hours. I think it would be just as valuable as any other conversation.

Peter: 11:37

Well, of course, yes, I mean it's going to take three hours and 49 seconds.

Dave: 11:43

I was going to say. I think we shouldn't have two British people having this conversation, because everyone's going to believe what we say, whereas we're being very, very dry and facetious as we say this.

Peter: 11:52

Yeah, it's understanding and facetious as we say this. Yeah, it's understanding, like if we think of, hey, we've got the next big chunk of incremental value, if we think that this big scale is going to take longer than whatever we've set as that period say it's a quarter then we need to break it down. So we know that we think it's going to take a little. We'll never know for sure, we're never going to be that accurate. But take a look, we'll never know for sure. They were never, they were never going to be that accurate. But we want to then say, okay, what are we going to do? And break down into months. It's like we know we're wrong but we still want to break it down.

Peter: 12:23

And until we've got something to say, okay, how do we make this small enough that we can understand? Can we get this little bit of it done in the next five days? And what can we do in the five days? What's that going to look like? Like, because that breaking it down and timeboxing in those pieces is what helps us understand how big is this comparative to the other things that we might want to do, or how many of these things can we potentially get done? Because with that that's the comparative size of the different things that we have Some of the estimation pieces or well, there's prioritization versus estimation. Prioritization comes from the impact, effort type things or from the cost of delay. If you can actually get to a numerical number of price to be able to understand that, then cost of delay can work really really well. Some things it becomes harder to actually be able to do something like that.

Dave: 13:12

But I think here we're diving off of things, like if you just stay on that conversation around understanding the work that needs to be done, and I always think that the focus on time if I have a team that's happy to focus on time and that's what they need in order to get things done, and it works for them, super happy for it Many of the times. So the focus on time becomes a policing mechanism. You said it would take X hours.

Peter: 13:37

It's now.

Dave: 13:38

X plus more than X. You know it's X plus something else. So what's going wrong? And I don't think that's a very useful conversation. What I'm looking for on the team and I always think of this, I always come back to sport, you know that one at some point. But I'm just thinking, if you're sitting there as a football team, you're trying to decide how to get the ball into the opposition's net. Your plan is not timing. It's not about passes and how many milliseconds it takes to do this and how many seconds it takes to do that. The plan is how are you going to work as a team to overcome the obstacles in front of you to get the ball into the net? And that's the conversation. It's how are we going to get these things done? Timing doesn't make sense. You're going to adjust and work on it, but you're looking at that to go. You know, we know what the goal is. Let's go work towards it.

Peter: 14:20

Right, but so the team that has been working together for some time, if they have no dependencies, can start to build up an understanding Notice the no dependencies part an understanding of what delivery will be.

Dave: 14:33

And the team that's been hanging around and working together for a while is a dedicated, persistent team. Yet now it starts making sense. Right Now it really is how do we tackle this problem? How, from everything that we've done in the past, from all the skills we have on the team, from the things we have in front of us, can we get to the end of this and figure it out?

Peter: 14:50

Yeah, Now that state is where you've managed to configure your organization in such a way that you have broken sufficiently the dependencies such that the teams can operate in that manner and you can build that. And that should be the goal. When you don't have that, which is the vast majority of organizations where you have dependencies into architectures which require other sort of teams to start looking after them, teams to start looking after them, like complex subcomponent teams that are looking after your AS400. And you need them to go and make changes to the AS400 before you can make changes to your system, or you'll deliver all of your digital front-end changes to the form and everything's ready to go, but until the backend system gets fixed. So you've got to work out how do I start to break those dependencies, how do I start to be able to have this layer deliver at the speed it needs to be able to deliver so that the customer can start to see the value of this? What am I going to do? How am I going to break some of those pieces?

Dave: 15:44

Well, what I find really interesting. This is part of our headache. Right, we always get involved in the problem pretty quickly and solutioning and all the rest of it. But what you're describing there is nothing to do with timelines. It's nothing to do with how much time will this take you. It's to do with what is the problem we're trying to solve and how can my team and your team work together. What do you need from us, what do we need from you and how can we make this work, which I think is really. Again, if it's the driving across the country, it's, you know, if we're, say, convoying together or we're meeting up at a particular place, how do we solve the problems in front of us to get where we need to get to at the time we need to get there, and it's problem solving. That's what we're looking at. That's estimation. Is this tool in a problem solving toolkit? It isn't a tool to somehow get a whole bunch of times and do some maths on.

Peter: 16:39

No, no, but we do need to understand how we will have people ask us. So we've got to do both. It's not either, or we can't ignore the outside world entirely and say, okay, I'm just going to go off on driving and work out how to get really good at driving so I can keep going in this way and I'll work out what my progress is towards those pieces. We can only do that independently if we don't have outside people who aren't like. Your mum is calling you and saying when are you going to get here?

Dave: 17:08

So if you don't have somebody, Well, I think it isn't quite that you don't have dependencies, because there are many situations where you will have those. But that's where the feedback becomes really important. So if I stay with that driving across the country, if I don't talk to my friends, family, whoever it is, for days at a time, we're going to get hounded by requests for updates and whatever Police will be notified or whatever it is. You know there'll be a whole bunch of activities that escalate because they're not getting feedback. But if they're getting feedback every day of progress being made and they can see real progress being made, not just miles, but actually you know, oh, you've got as far as Memphis, as far as whatever, the next one, so on, you can see the progress being made. Those escalations of communication and dependency, management and everything else fall by the wayside they do.

Peter: 18:06

So the escalation piece, if you've got those updates you're still going to have. In parallel to my team delivering this, I've got a trade show where I have to print out banners on big pieces and put them up and build all the marketing material, which takes just as long as doing these other pieces. I need to know what to put on that, and so I need the cloud. I need to not just be able to understand where you're at now, I need to know how long you what you think you'll be at then or where right and and what's changed?

Dave: 18:32

are we still touching the same touch points that we said we would be, or or are we beginning to say you know what? We're going to have to cut this out, we're running out of time. So there is, I think there's. This conversation has been quite wide ranging because we're touching on both what the teams worry about.

Dave: 18:47

It's all interrelated that's why, yeah, and we're looking at you know sort of say, call it product manager, product owner what they're looking at, the technical leads and what they're looking at the technical leads and what they're having to deal with. And I think you know estimation. It isn't about the accuracy of the numbers that you're getting. It's about the fact that those conversations are being had continuously and that people are very direct and open about when they find something out which changes some of the things that they've committed to or are in the future on the roadmap, which are going to be impacted by what you're discovering at a particular time.

Peter: 19:24

Yeah, and it's creating an understanding in the organization through this as well. The bigger the thing that you're asking me to come up with a top down estimate for, the less accurate it will be, the more uncertain it will be.

Dave: 19:38

And if you're not happy with what you get, you can't just go and re-estimate, right? Yeah, you can pull things off the roadmap so that there is less work to be done, so that the numbers work. But it isn't about just revisiting those estimations until you get the number you look for.

Peter: 19:53

Yeah, right. So it's saying okay, okay, I'm comfortable with the estimation. So if I give you an estimate estimate which says it's going to take three to eight weeks, it's because right, it's because I think it'll be somewhere in that range, based on what we know at this point in time. So it may take eight weeks, but it may also take 12. At this point in time I don't know. It's like, until we start work on that, I'm not going to have a good understanding, and so the best way to start to learn is like start work and if I have no idea whatsoever, I'm going to tell you it's going to take a year and a half because until the um it's the uh spox estimate with scotty, you know it's like, say 24, it's gonna take us 24 days. No, it'll take 24 hours. I have, there you go. I feel like we're going to have to look that up.

Dave: 20:38

Put it in the notes. How do we wrap this one up?

Peter: 20:43

So I think some of the key points that we're talking about there is that bottom-up estimation.

Peter: 20:50

Thinking you're going to get accuracy by adding up exact time usage or percentages of person's availability is not going to get you to anything that is usable in any way, shape or form, and it's largely a complete waste of time, especially the further out you go.

Peter: 21:05

Like if you're looking far into the future and thinking that I can add up 300 stories and in that fine detail into how long it's going to take to do this, yeah, you're kidding yourself, especially for software, but even for anything really. I mean, we know that there's just going to be too many delays. Even the hospital example we started with there that even with the best will in the world, things happen. Say, supplies become unavailable, you are not able to get the piping that you need to be able to run this, or the store runs out of the valves you need typing that you need to be able to run this, or the store runs out of the valves you need, or something like that. There's so many things that can potentially go wrong that prevent you from doing all of the things exactly in the time and the order you need, which is why you have people coordinating that and trying to solve those problems and think ahead. And this actually gets us into an interesting conversation around risk that we don't have time for today, but how do?

Dave: 21:57

you manage and mitigate risk't know about you, but I'm getting hungry. I'm not hanging around for a risk conversation so.

Peter: 22:04

So there's that. So top-down estimation. Understanding that building uh teams that are capable of delivering in a consistent manner on an ongoing basis and removing dependencies from those teams so that you can start to measure progress and see progress, and making sure that gets radiated are key ways to start to build the system that will enable you to get to more reliable estimates, essentially because I'm going to have a better understanding of how long it's going to take me to get there. Because I've got better at doing this. I've got better at looking at work and deciding how long that work's going to take me to get there. Because I've got better at doing this. I've got better at looking at work and deciding how long that work's going to take.

Peter: 22:40

And another part of this is like breaking it down into small enough pieces I can understand what it is Like it's got to be. If, if it's something absolutely massive beyond the scope that I can't fit in my head, then anything that I'm going to tell you about how long it's going to take is going to be garbage Cause it's like I don't know. It's like it's a. How big is the bread box? Right, that's the. I'm just not going to know. Okay, what would you? What would you add to that?

Dave: 23:01

I think I'm going to keep this really very short, just add two comments. One is you can absolutely plan long-term delivery, fixed date, fixed scope, things like this. There are constraints, but you can at least give an indication of what is going to be available for that trade show in the future. Just the idea that that's not possible is just.

Peter: 23:22

It doesn't work in most organizations today, and then the second one is it's a conversation, that continuous conversation. Yes, yeah, I'd agree with this. I hope we actually got our listeners to the point. They could understand how you get to that date for the trade show.

Dave: 23:41

If not, I think we, you know, there's a information that, like we, we kind of touched on a lot of different things. Maybe there's comments or questions coming in. We can dig into one or two elements in more detail, if that's useful to people.

Peter: 23:48

Just let us know, as usual, of course. Yeah, feedback at definitely maybe agilecom and uh, there you go, and, as always, don't forget to hit subscribe. We always like new subscribers. They send us interesting questions, right, exactly, exactly, okay, until next time. Until next time You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.