📕Software Estimation

Software Estimation: Demystifying the Black Art by Steve McConnell

Estimation (and especially negotiating/problem-solving with business teams around estimates) is one of the most difficult and stressful parts of my job. Programming tends to be more straightforward: you can write tests and get immediate feedback on most of your work. But it’s harder to know whether you’re on track with estimates. The feedback cycle is long, and imprecise because projects are constantly changing.

But even if estimation is never perfect, there are lots of things you can do to improve—to get good enough to plan and push forward. This book is full of specific estimation techniques and equations for teams/projects of various sizes and stages, but the general lessons about estimation and negotiating commitments are what really stuck with me.

(More detailed notes in 🔒 Private Note.)

Key Concepts & Takeaways

Estimates vs. targets vs. commitments.

In any discussions with business/product teams, there are three interconnected concepts that tend to get confused:

• An estimate is a prediction of how long something will take or how much it will cost.
• A target is a business objective.
• A commitment is a promise to deliver some defined set of functionality at a specific level of quality by a particular date.

As software engineers, we need to recognize what the conversation is actually about so that we can reframe negotiations. Commitments can be negotiated, but estimates themselves should never be negotiated.

Keep estimation and planning separate.

“Estimation should be treated as an unbiased, analytical process; planning should be treated as a biased, goal-seeking process.”

The goal of estimating is accuracy. The goal of planning is a particular business result. Combining estimating and planning “tends to lead to poor estimates and poor plans.”

Instead, estimate the work first. Then put it on the calendar and figure out how much it’ll cost.

You can’t beat the Cone of Uncertainty.

You can’t estimate software accurately until you know exactly what you’re building. This might seem obvious, but in my experience business stakeholders often fail to appreciate the level of detail needed in requirements before accurate estimates can be developed. And even software engineers underestimate how inaccurate estimates might be at the start of a project.

This visual was a really powerful lesson that’s stuck with me, and something I want to share with the whole team any time we embark on a new project in the future. 😁

Estimate consistently if you want to know how accurate your estimates are.

An estimate is ultimately a guess. But it can be a good guess or a bad guess. The only way you’ll know if your technique is sound is to choose a consistent process, stick to it, measure the results, and reevaluate at regular intervals.

A few rules of thumb and estimation methods that are better than unstructured guessing.

The book is full of more specific techniques and equations for teams and projects of different sizes, but there were a few rules in particular that seem simple to introduce and useful even for the smallest of teams:

• Decompose the work before you estimate. Details tend to hide in big tickets, so break down the work and sum up estimates for smaller tasks.
• “Count, compute, judge.” Prefer counting something directly (pages, inputs, components, API endpoints, requirements). Then fall back to computing an estimate from calibrated data (e.g. from historical project data). Only then fall back to expert judgment, which is the least accurate.
• Avoid single-point estimates. Estimates are rarely 100% accurate, so estimating with just one number (e.g. promising a specific number of days or a specific delivery date) often conveys a false sense of certainty. Instead, estimate a delivery range, and don’t make it too narrow. (The Cone of Uncertainty can be helpful here in giving a baseline range of variability for project stage.)
• Even a 15-minute estimate is better than an off-the-cuff estimate. Don’t give into the pressure for an off-the-cuff estimate — they’re the absolute worst kind of guess, and no matter what kind of caveats you give, the business team will often try to hold you to it. Even 15 minutes to step through a process will get you a better result.
• Get multiple estimates from a group and look for convergence. Especially if you have to rely on expert judgment, get multiple people’s expert judgment and look for convergence. If several people independently come to the same estimate you’re probably on track. If estimates diverge, discuss the differences to better understand the ambiguities in the work.