Agile Estimates. Builders Estimates. Not the same.

Gary Straughan: Builders estimate, agile developers estimate. I want estimates from builders. I don't want estimates from developers. And there's no conflict here because we're talking about two completely different things.

Welcome to Development That Pays. My name is Gary Straughan and welcome back to this short series on agile estimates and estimating. If you'd like to catch up, this link will take you back to the beginning and deliver you safely right back here.

Now we have a couple of episodes under our belt and already there's been some pushback including this rather wonderful comment. "I get the point that it would be nice to work without the pressure of estimating, but I think that none of the no-estimation advocates would hire a company for building a house that does not give an estimation or fixed price for the cost of the house. I would not pay for a software team that can't give me a rough idea of the cost for the features that I want."

I love this comment because while it hints at two common misconceptions around agile estimate. Two misconceptions that I'm going to call apples and oranges and cause and effect. It also mentions builders and I've noticed that in discussions around estimates and estimating, builders often seem to get a mention.

Let's talk about builders a little bit more. I've yet to build a house, but I've done my fair share of remodeling. My most recent project, I should say our most recent project, was to swap out these horrible old doors for something much more fancy.

It's a project that's been, well a very long time in the making. It's taken us the best part of a decade to find the perfect door. But having found it, we kicked things off by getting two things. A quotation, quote for short, from the door company, and an estimate for the preparation work from a builder.

That's right, I admit it, I asked for an estimate. We'll get to whether that makes me a huge hypocrite in due course. But first it's worth taking a moment to think about why it is that the door company provided a quote and why the builder provided an estimate, and it's all to do really with certainty or the lack thereof.

The door company we went with was the very first company that we visited some 10 years ago. I know for certain that they've built a lot of doors, they've installed a lot of doors. They are very, very experienced and that experience has taught them that given the right preconditions, we'll talk more about those in a second, given the right preconditions, things go smoothly most of the time. That level of certainty allows them to provide a fixed price, as I said, a quote.

Now the door came with very many preconditions, including but by no means limited to dropping this big lump of stone by a couple of inches, flattening the arch at the top and straightening out the sides. Time to engage the services of a builder.

The builder we went with has been my neighbor for the best part of two decades. I know for sure that he too has a wealth of experience and his experience has shown him that nothing is certain.

My house, like many here in London is well over a hundred years old. You never know what you're going to find when you start tearing things apart. That's why my friendly neighborhood builder provides an estimate.

The estimate is the price I'll pay if things go reasonably smoothly, but if anything nasty is discovered, well the builder and I are going to be having a conversation, and inevitably I'm going to be paying more money. I think you know how these things work.

Now all this talk of certainty or lack thereof sounds a little bit like, well the very reason that we do agile. We treat the world as being very uncertain, so we go away and build something, get it in front of the customer and go on from there. Inspection and adaptation all the way.

So I have a question for you. Is our world closer to that of the door company or is it closer to that of the builder? Well, clearly it's the latter, which is a relief. I don't want to be providing quotations and I'm sure you wouldn't want to be doing that either.

But what about providing estimates? Well, that very much depends on the definition. Nine times out of 10, when we agile types talk about an estimate, we're talking about an estimate for an individual work item. I'm talking story point estimates or T-shirt size estimate. But whatever the unit of measure, we're referring to the smallest thing we can possibly ship.

That's nothing at all like the builder's estimate, which applies to the entire job. The common misconception then is that they're somehow the same, whereas in fact they're different in kind, apples and oranges.

We have another misconception to uncover, but first I have another question for you. What is our version of the builder's estimate? If we're talking about say, a major new feature, is it reasonable to ask when it might be complete? And is it reasonable to ask how much it's likely to cost? Well, of course it is. So yes, we definitely do have something here, and unfortunately the word that's often used to described that thing is, you guessed it, an estimate.

I don't know about you, but I find the clash of terms a little bit unfortunate, so I prefer to use the term forecast. Now that might seem something of a stretch, but when you think about it, most of the cost in an agile team, and this is really, really true of software teams, most of the cost is tied up in the people paying their wages, keeping the lights on, that kind of thing, which means that the cost per period of time, per week, per month or whatever is more or less constant. What that means is you know how long something is going to take, you know how much it's going to cost. But in another way, if you have the forecast, the duration, then you can pretty simply calculate the cost.

Now where were we? Ah yes, apples and oranges. Looking at this comment again, I don't think this person has fallen into that trap. This is very clearly the builder's estimate and the reference here, they're paying for a software team tells me that we're talking about a significant chunk of work. While some might call this an estimate, perhaps even a big estimate, I prefer to think in terms of a forecast.

Builder's estimate, agile forecast, that's an apples to apples comparison. So far, so good. But there's something else hiding here. The comment begins by talking about our small estimates, story points, T-shirt sizes and the like. That's a problem because it suggests cause and effect. That the way we get to a forecast is via estimates, and yes, common practice is exactly that. We start with estimates and we produce a forecast. The misconception is that that's the only way to do it.

This is one that I bought into for years, actually less bought into, more I never thought that there might be another way. If the same is true for you, the next episode will blow your mind. Not only will I be introducing you to a famous, nay infamous advocate of no estimate, I'm going to be showing you what he showed me about how to forecast entirely without estimate.

Join me then. I think, yes, I'm pointing the right way for once. I think it's this video right here.