Estimating. Can’t live with it, can’t live without it—or can you?

In 2013, 11 years after agile estimating was created, the #noestimates movement took hold. It was a call to stop sizing stories and instead “just start developing.” The argument was that smart, high-functioning agile teams should be trusted enough to work intelligently. Estimating takes a lot of time, so it’s more useful to start working iteratively, which is the quickest path to a shippable product.

Martin Fowler weighed in, saying, “Estimation is neither good nor bad.” Ron Jeffries said, “Estimation is Evil.” Two months later he corrected himself, saying “Estimation is a necessary evil.”

I agree that estimates take a lot of time. I disagree that the answer is abolishing estimating and “just start developing.”

A short history of estimating

To understand where we’re going, we have to understand how far we’ve come. Prior to 2001, many teams used tools like Microsoft Project to estimate projects.

The main problem with this was that it prematurely focused teams on the details and took the eye off the big picture. Instead of asking, “Should we keep building this?” teams were incorrectly stuck focusing on the details.

In 2001, the Agile Manifesto was created, and many of us started estimating stories and working iteratively. This was a huge improvement. People such as Mike Cohn popularized Planning Poker, and many agile teams began using the Fibonacci sequence to estimate stories and tasks.

We later improved upon that and started using Small, Medium, and Large estimating, which is quicker and easier than Planning Poker and still gives us a lot of useful information about the relative estimated size of stories.

This way of estimating agile projects was better, but still not a perfect fit. The reality is, people abuse estimates and start doing things such as measuring individual performance against them, and treating them like guarantees instead of estimates.

But if estimates take too much time, and technical teams don’t enjoy it because it too often gets abused, and it doesn’t really yield an accurate picture of time and cost, where does that leave us?

It leaves us with a disconnect: stakeholders need some way to make decisions around software development. We can’t simply abolish estimating all together.

The answer: stop estimating, start budgeting.

Budgeting projects uses a top-down approach, where you decompose only so far as you need to in order to have enough information to make your decision.

Budgeting can be done well in 20% of the time it takes to estimate, and I believe it is the missing link between the current disconnect between stakeholders seeking an answer to “How much is this going to cost?” and the #noestimates movement.

How do you budget for projects? Read on at Budgeting vs. Estimating for Agile Projects.