What I really want to know of course is how much it will cost, and what I can plan for.
How much will it cost? What will I get? When will I get it? All of the anxiety faced by organizations building anything that takes more than two people to build it, can be traced back to these three items.
Answer these questions consistently and with a bit of accuracy and you’ll build trust. Actually you’ll look like a god.
The frustrating truth is that we humans are terrible at predicting the future—even a future over which we have a high degree of control. Ask 100 people how long they think it will take them to drive to the mall, and then time how long it actually takes, and you’ll find, on average, it takes a bit longer than most people thought.
We are an optimistic species, and want to believe in our own powers so much, that we will consistently underestimate the amount of time it takes us to do something.
Plot the results of tests like this on a graph and you’ll get a lop-sided curve. A curve that tells us that to achieve 80% accuracy in our predictions we need to at least double every estimate we make.
This is data, not opinion: humans suck at estimation.
There’s probably even some fancy reason for this from an evolutionary perspective—our ancestors were perhaps more likely to embark on a long journey to new hunting grounds if they could trick themselves into believing it wouldn’t take so long.
And like so many things that contributed to our survival in a land of scarcity this optimism is contributing to low morale, wasted money and energy, and—in some cases—threatening the economic viability of our organizations.
Business as usual.
The way we usually estimate a large project is by breaking it up into smaller pieces then estimating how many hours it will take to do each piece. We then add up those pieces and voila! We’ve got our funding and got our plan.
Everything goes well until 3 months before our delivery date—why it always seems to be 3 months I have no idea but that’s what it is—and we “suddenly” realize we’re not going to make it.
Names are called, fingers pointed, panic buttons pushed, corners cut, overtime authorized, and the whole organization turns into a frenetic warren of activity. I’d like to say they stay in this frantic state until they make their delivery and then do a calm post-mortem before starting anything new and figure out ways to never do such silly planning again. But they don’t. In fact most organizations I encounter have been in a state of panic so long they can no loner imagine another way.
They believe that this is what business feels like—what it should and needs to feel like.
Only it doesn’t.
If only there were a way to keep the natural optimism of our brains from tricking us into making these impossible predictions and committing to ridiculous plans.
We could simply double our predictions but most organizations have no stomach for that, and our brains are too smart anyway. We’d be halving things in our brains even as we double them in our spreadsheets. And end up right back where we don’t belong.
It’s all relative.
The answer is elegant, simple, and even takes less time. The answer is relativity. Not Einstein’s at least I don’t think so. But relative estimation.
Imagine you have a large pile of rocks of different shapes and sizes and you’ve been tasked with getting a reasonable estimate of the weight of the entire pile.
One way to do it—the way most of us try—is to go through the pile rock by rock and guess a weight for each. Now imagine you’re not very good at guessing weight—and, as we’ve seen above, you aren’t.
This is the situation organizations face when estimating large bodies of work. The compounding of errors leads to incredibly skewed outcomes. This effect is even worse when those making the estimates are pressured by their leaders to “find a way to do this as quickly as possible” meaning their estimates are often even more optimistic than usual.
I was just working with a team who’s manager would regularly re-estimate for them “that thing you said was big? yeah that’s actually small.”
One imagines his bonus is tied to estimates more than outcomes.
This situation is toxic of course.
Now imagine you go to that pile of rocks with a team of people who handle rocks all day every day. You then ask them to work together to pick out a series of rocks definitively representative of specific sizes. This rock they decide is a small, this one a medium, this on a large and so on.
Armed with this benchmark the team quickly sorts the rocks into piles based on size counting as they go.
You then weigh your benchmark rock for each pile, multiply the number in each pile by the weight of the benchmark rock.
You now have a reasonably accurate estimate of the total weight.
This method of relative estimation is much faster, more fun and way more accurate than any other method you can choose and it has one more benefit: your team will have a good idea what they are building and will have had high-level design conversations and generated a shared understanding of the project along the way. They’ll most likely have identified the high-risk pieces so those can be tackled first.
Here’s how it works.
You break your project up into the large features, things like “login” “enter personal data” “browse” and “checkout.”
You then gather your team together and say this is what we want to build and you ask them to break these features down into small chunks. Chunks of value.
This means each chunk needs to have a who, what and why listed for it. We usually recommend a format like this “As a site visitor I want to browse an item category, so I can choose something to buy.”
This is a story. And each story can be broken down even further like this: “As a browsing customer I want there to be only 20 items per page so I don’t get overwhelmed with info.” and “As a browsing customer I want to see how many items are in my shopping cart and a total of dollars spent so I can know if it’s time to check out.”
Once the team articulates a full set of these stories they can quickly bucket them into size buckets like Small, Medium and Large. Along the way they’ll have design conversations, create relationships with each other and a shared understanding of the product.
When you assign a numeric value to each group—most prefer a fibonacci sequence like this: 1=XS, 2=S, 3=M, 5=L, 8=XL—you can add these up to get an overall sense of size of a project. If your teams have been tracking how many points they can do per iteration—this is called velocity—you can quickly figure out how much time a set of functionality will take and thus derive the cost and timeline.
This process will also surface the gaps in your thinking. Something invaluable in lowering risk.
Too many products out there have been built by people who just start building. Estimation in these organizations is a grind, products are often soulless, and the work environments almost always suck.
That these problems come be traced back to our natural human optimism is a healthy dose of irony.
Want to learn more? Sign up for my free email updates and ask me anything.