Is estimating due to lack of trust?
Rob Bowley’s “Estimation Fallacy” session at SPA 2009 contained some discussion about trust. In particular, this pithy statement was made:
Estimates are due to the lack of trust between the business(*) and development team.
There have been a number of descriptions of “estimation-less” approaches. Is it simply a case of lacking trust?
It’s probably a bit more complex than that.
Valid reasons to estimate
Why would we estimate the effort and cost of a project, a release, an iteration, a feature?
To evaluate if the benefit of the project outweighs the cost. Say we have an estimate of the value a project or product may bring. I’m prepared to pay you 1.000.000€ if you deliver certain product. Do you do this project? Only if it will cost you less than that amount to deliver it. Of course, we should try to break the product down in smaller Minimal Marketable Features so that we can deliver sooner and get value earlier.
To make scope tradeoffs. Say we have a given budget and time: we need to show a demo at an industry event in 3 months with the current team. Which features shall we keep, which can we postpone? Which features will give us most “bang for the buck”? Of course, we start by prioritising by value, but three lower valued/lower cost features may have more effect than one higher value expensive feature.
To know how to distribute resources over multiple projects. Say we’ve got 20 projects we could start and we have 50 developers. Which project(s) do we start? How do we know where the developers will have the most effect? Of course, we start the fewest possible projects simultaneously, but there’s a limit to the number of people that can work on one project.
To make reliable promises to others. “Can we deliver this game before Christmas? If so, we need to get the marketing campaign started.” Of course, it would be easier if we were all in the same multi-functional team or if we had a real cross-company value stream. But sometimes we do have to coordinate with others or agree on contracts.
To know when to exercise our Real Options. Real Options tells us we need to make a decision at the optimal decision time. This is the deadline minus the implementation time of the most costly option. How do we know the implementation time?
No estimation? Really?
I agree that spending inordinate amounts of time on estimating is a waste of time. But no estimation? If I look at the “estimation-less” methods I see a few different approaches:
- Break down the work in approximately even-sized amounts of work. In effect, you can say that each item now has a cost of ‘1’. Then you can simply count the number of items and use throughput and cycle time to make your estimations. How do you know that the items are approximately even-sized?
- Count the number of user stories, even if you know they have different sizes. In the end, it doesn’t matter much, some stories will go faster, some stories will go slower. Over a release many of those differences cancel each other out. What do you call the number of stories you typically deliver per release?
- Give each item a high level estimate (in points, gummi bears or t-shirt size) and track (or estimate for the first few releases) how many of those you can reliably deliver. Concentrate on those items were estimates matter.
The only really estimation-less method I see is one where features are prioritised purely based on value and then pulled for implementation one by one, without caring how long it would take to implement. I think this is what’s described by Joshua Kerievsky. Even then, he talks about micro-releases, so the features must have been broken down into reasonably small pieces.
That’s about how I work on projects where I’m both developer and customer: user stories are prioritised by value and released in micro releases. The features are small enough to be implemented in a couple of hours. In any case, I set a timebox and revert if implementation takes too long. I know the value; I know how much I want to spend; most of the time I correctly estimate that the cost of the feature is within my budget.
Trust: necessary but not sufficient
Estimations are useful but fraught with many problems. Trust between everyone involved helps a lot, but it doesn’t eliminate the need for estimates in most circumstances. Let’s look at some of the issues related to estimating and see what the root causes are. Maybe we can do something about the root causes.
And why don’t we talk about estimating (business) value?
(*) I really, really hate the use of the expression “The business“. IT, the development team is part of the business. If we want more trust, can’t we start by seeing them as one team?
