Best Agile decision-making tool is not an estimate

Let’s start… with this guy: my friendly neighbourhood builder. He - together with his small team - was responsible for swapping these rotten old doors For this single aluminium door.

But before he did any of that, he provided me with an “estimate”.

The estimate - let’s call it the builder’s estimate - answered two questions: When will it be ready? And (for me, the far more important question) What will it cost?

It’s worth taking a moment to think about the “margin of error” here

If you’ve ever dealt with builders, you’ll already know that it’s going to take longer and it’s going to cost more.

And that’s expected. After all, it was an estimate, rather than a quote.

But how much more?

The pain can sometimes be hidden in percentages, so let’s talk cold hard cash.

Say my builders estimate for this project was £10,000.

If the final bill comes in at £11,000 (10%)… I’d be okay with that.

£12,000 (10%) or more, and my builder goes from “friendly neighbourhood” to “neighbourhood”

Margin of error-wise, there’s an unspoken agreement that if things go smoothly the final bill will be within 10–20% of the estimate.

And that NARROW margin is what makes the builders estimate useful for decision-making. Specifically, the decision on whether to go ahead with the project in the first place.

One more thing before we move on.

Imagine the bill came in at £16,250. - a full 62.5% greater than the original estimate.

That’s an oddly specifc number! Yes, isn’t it.

I’d be okay with that too, as long as it reflected an AGREED change to the original spec.

That’s another property (!) of a builders estimate: it gets adjusted in light of new information.

Forecast

Question for you: what’s our AGILE equivalent of the “builder’s estimate?

It’s not the estimate.

Same name. Different animal. A Story Point estimate:

Applies to a single work item, rather than to a “body of work” Tends not to updated in the light of new information Answers a different question // “relative complexity” And does so with a huge margin of error of ~62.5% or thereabouts. // I could do extra voice-over later.

No, the equivalent we’re looking for is the forecast.

If I FORECAST that a certain piece of functionality will be ready in 10 weeks,

I’ve answered the question When will it be ready?

I’ve also answered the question What will it cost?

At least I have for a software development team, where the majority of the cost is in paying the team keeping the lights on. Put another way, if I know how long it will take, I know how much it will cost.

Great for decision-making - providing that the margin of error is reasonable.

If I give you a forecast of 10 weeks, I’m sure wouldn’t be surprised if things run over by a week (10%) But you’d be less happy overrun was two-weeks or more (20%)

Interesting, isn’t it, that we AGAIN have an unspoken agreement of a margin of error in the range of 10–20%

And, yes, it’s achievable. Good enough for decision-making in my book.

Not only for the go/no go decision, but for coordination with other activities. But the reality is that few Agile teams forecast at all. Either because they think it’s “not a thing”. Or because they think that it requires too much work.