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 estimating. 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 remodelling. 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 neighbour
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 neighbourhood 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 estimates. 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 describe
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 - 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 #noestimates,
I'm going to be showing you what he showed me about how to forecast entirely without estimates.
Join me then. I think, yes, I'm pointing the right way for once. I think it's this video right here.