Mike Lyons (with a second speaker) explains why precise, absolute estimates are unreliable and advocates relative estimation for agile work. Using a coffee-cup size analogy (espresso, mug, large 'soup' cup, travel cup), the talk separates volume, complexity, and uncertainty as components of estimation. The speakers introduce story points as a relative measure that captures those components, recommend using a Fibonacci (or modified Fibonacci) sequence for sizing, and clarify that story points are not direct measures of time — they represent combined scope, risk, and effort and should be estimated by the people doing the work.
Chapters
You know, I'm like really bad at estimating things. You can, you can check with my wife. She, I was working on a project in the backyard. I thought it was going to take maybe a weekend.
I'm building some arbors for us to do some planting on.
I thought it'll take a weekend. Well, you know, three weekends later and five trips to the, you know, home improvement store and I'm still, I'm still not finished. Well, that's because I am bad at absolute estimation, at precise estimation. And I, I bet if you're honest, like you're bad at it too. Humans are kind of just notoriously bad at precise and precision based estimation. When it comes to like exact time or distance, we're just not great at it. But we know what we are really good at. We're good at relative estimating. We're good at comparing one thing to another. We call it relative estimating. And so let's talk about some of the ideas behind it. And to do that I want to talk a little bit about one of my favorite things, coffee. I do like coffee. And so I'm going to introduce this idea of different sizes of cups. So let's take this first example here, an espresso cup. You might be familiar with this, the small espresso cup. And then let's take another example, the regular mug of coffee. And then finally a third example, the Mike Lyons cup of coffee that you could serve soup in. It's more like a bowl. Gigantic. Right, so let's talk about sort of the comparing these things to each other. So which, which is the smallest? Well that's easy. It's the espresso cup. Right. And which is the biggest? It's the Michael Ions soup cup. And then somewhere in the middle we've got the regular coffee mug. So we know the smallest thing is the espresso cup. Well, how much more volume do you think the mug is? The coffee mug? Do you think it's maybe three times as large as the espresso? Maybe five times as large? Let's call, but let's say it's five times as much volume as the espresso cup. How about the soup cup, the Michael Irons cup? Is it, you know, is it 13 times as big as the espresso cup? Is it 20 times, let's call it 20. Let's say it's 20 times as big as the espresso cup. So here we have this sort of relative estimation. It's not super precise, it's not meant to be, it's Just enough so that we can know the differences between the two. It's not based on absolute measures either. It's not like the espresso is 2 ounces, the mug is 10, and the large one is 20 ounces. Although that may be the case. We're not looking for that level of specificity here. We're just looking relative to that. Well, let's consider a fourth option, the travel to go paper cup. Well, wait a minute now. Where does that fit? Well, it's not ceramic. So now all of a sudden, there's this complexity factor. Wait a minute. We've never. I don't know how. I don't know how much fits in there. It's got a sleeve on it and a lid. Like, none of the other cups have lids. So now we've introduced this idea of complexity. It's made of a different material. It fits in a cup holder, whereas the other ones don't. There's just some sort of unknowns and complexity there that we don't. We don't really understand. There's. There's some risk there, too, because unlike the ceramic cups, you know, the paper could tear easily or the bottom could leak. Is the sleeve going to protect, you know, people's hands from being too hot? So there's some uncertainty. So we have volume and complexity and uncertainty across all of these, and they're relative to each other. So maybe that one, the paper cup, Maybe that's like a 40 or something that's just. That's bigger than and more unknown than the espresso cup. My point is that we want to. We want to have estimates that are based on something other than precise time or precise measurements, because we're in this land of creating things that have never been built before. So we need some other mechanism than an absolute measure.
And so the most common technique for this is to use something called story points. Story points are nothing more than a measuring technique that captures the volume, the complexity, the uncertainty and risks that are involved in the thing we're trying to release, the thing of value. We call them story points. We might have referred to them as espresso points in the coffee example, but they're used for relative estimation, and they contain all of those components needed for us to make that estimate.
And we follow a defined sequence.
We call it the Fibonacci sequence. Each number is the sum of the two preceding ones. So that is 0, 0, then 1, then 2, then 3, then 3 plus.
2 is 5, and 5 plus 3 is 8, and 8 plus 5 is. I get confused a public math. And 8 plus 5 is 13 and 13 plus 8 is 21.
Now, just a note here. Some teams will use the modified Fibonacci sequence. And here from instead of 21, they'll shift to 20 and then move on to 40 and maybe 100. You have freedom to decide on your team which you'll use. Some teams find it easier to use 20 and 40 rather than 21. And whatever the next Fibonacci number is. That's not the critical component. The critical component is to realize that these are relative estimates and use the story pointing technique and the Fibonacci sequence.
Something to consider about relative estimates for user stories is that they're not concerned with time. A common misconception is that user story points relate to time. People will want to say, well, we can get eight story points done in a day. That may be true, but the next day it may not be 8, it may be 3, it may be 20.
What?
We don't care. We don't necessarily associate those with time. There is no direct correlation between user story points and time.
When teams look at user stories and.
Begin to do estimation and the estimate they give, it includes all of the pieces of design, build, test and potentially deploy that unit of value. So it's gotta include all of the things needed if we're going to have documentation, say security reviews, any peer review, the code checked into the code library, all of that has to be included in this estimate. So it takes everybody to estimate. There's not just one person saying, well, well, that's that user story is a five or that user story is an eight. It's not just one person, it's a team activity. A couple other quick notes. There is only the team members who are doing the work actually get to estimate. So Scrum masters, sorry, you don't get to provide the estimate. That's going to be the team members, product owner. Same thing for you. You're there to answer questions and provide clarity as needed, but the people who do the work will provide the estimate. Teams get better at this over time. Estimates get better. Their fidelity gets better over time. But relative estimating, that's the key. That's how we do estimates on agile teams. We don't do hours based estimates or days based estimates. We avoid that.
We use relative estimation using user story points.
