Contact
Menu
Contact

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

Debbie Madden
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.

A Little Non-dogmatic Technical Mentorship
Can Go A Long Way

 

Do you ever feel like your team is running 1,000 miles per hour in the wrong direction, and you're not sure why? Sometimes, a chat with a peer is all it takes to give you a meaningful perspective to help you course correct, or to give you the courage to continue on your current path. 

For friends of Stride, we're offering a free Peer Chat. Tell us what's on your mind, and we'll share our experiences. Don't be shy, we've been there ourselves.

You May Also Like

These Stories on Process

Subscribe by Email

No Comments Yet

Let us know what you think