A History of Estimating and Why It’s a Waste of Time

Nov 06, 2014

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

Screenshot of a Gantt chart in Microsoft Project

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.

A set of agile planning poker cards, with the point values: 0, 1/2, 1, 3, 5, 8, 13, 20, 40, 100, and a question mark

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.

You May Also Like

These Stories On Process

It's the third week in a row that your team has given the same update: "We are almost done with the 'previous orders' feature." You are frustrated with the lack of progress and the inability to shift to more important work—like that feature you wish the ... read more

Josh Seiden, the fourth speaker in Stride's Leadership through adversity speaker series, spoke about the value of focusing on outcomes, defined as: "measurable changes in behavior that drive business results."   read more

To start his talk, psychiatrist and psychoanalyst Dr. Kerry Sulkowicz admitted to being at a bit of a loss when asked about best practices for leading through a pandemic. "The honest answer is I don't know," he stated, "because none of us has lived ... read more

Taking direct aim at the narrative of the "all in" entrepreneur who takes extreme risks and depletes their bank account before ultimately succeeding, noted NYC VC Charlie O'Donnell started his Stride Consulting “Leading through Adversity” talk on May ... read more

Get Email Updates