Software Estimation Without Guessing: Effective Planning in an Imperfect World

by George Dinwiddie

estimates are all you can know about the future. Within limits, estimates can help you make decisions.

Numbers are not the goal. Successful outcomes are. Those footing the bill would rather have a successful outcome than an excuse to blame the estimator.

You can go faster when you can see further than the work right in front of you. You can strategize ways to incorporate the bigger picture. You can avoid painting yourself into a corner, far from the door you want to go through.

if you’re meeting a hard deadline, you might have better options than developing User Stories in prioritized order until you run out of time.

Estimation is a tool rather than a goal in itself. Maintain focus on the real goals: the outputs, the outcomes, and the impact of the system you’re building. Estimation is a tool for achieving these goals more reliably in an uncertain, error-prone world. Estimation lets you see into the future and make decisions about the path you’re on, before you reach the endpoint.

isolation between value & cost estimation carries the risk that the two estimates will depend on different assumptions.

In its lifetime, a product is produced and enhanced as a series of projects. Each step along the way has a cohesive intent that clarifies the focus of the moment. Fielding a viable product that people will buy is a project. Enhancing that product to generate greater revenue is a project. If you can state your next product goal in a sentence, then trying to achieve that goal is a project.

The most critical estimates are those on which a decision depends. If you’re not going to change what you’re doing or how you work based on this estimate, then why are you creating it? Why does the answer matter? Deciding to start, continue, or cancel a project are examples of this sort of decision.

If you don’t understand what question you’re answering, you won’t understand how much accuracy or precision you need.

By specifying with too much precision, you may make an estimate unnecessarily inaccurate.

Remember that you are creating estimates, not measurements.

Even measurements have imprecision.

delays during development will quickly swamp the work itself in terms of time consumed. Therefore, experience with the client and understanding the likely delay durations may be more valuable than understanding the time required for the development work.

. The simpler way of estimating, especially when starting something new, is by comparison, i.e., comparing the things we want to know about to the things we already know.

There are big benefits of keeping durable teams together and bringing the work to the team. One of these is having a track record for the team and how effectively it works together. Another benefit is that the team doesn’t have to ramp up new working relationships for each project.

the term “epic” suggests that the story is intended to be further split before implementation.

For short-term estimates, such as how much work a team can accomplish in the next two weeks, just count the stories. If you’ve kept track of how many stories the team accomplished in the last two weeks, that’s probably a close enough estimate, and requires less work.

delivery is more important than being full-featured.

For longer term estimates (e.g., longer than a few months), decompose into a half-dozen to three dozen parts, not hundreds.

in all the cases I’ve heard of people developing a "complete backlog" at the beginning of a project, there was always new information uncovered later.

Doing something harder is not necessarily more valuable; it’s just more expensive. In any event, our ultimate goal is not that to have more Story Points.

We often focus on our peak speeds to the detriment of minimizing the time to reach our goal.

Focusing on short-term measurements tends to blind us to the longer-term progress.

In the end, it’s not about the number, but situational awareness. Discover what the possibilities are and where the dangers lie. Use your estimates to sense the world around you and make visible the intangible and ineffable. Mark the areas you want to avoid. But whatever you do, do not fool yourself into believing that estimates are truth.

People talk about estimates being “wrong” when reality fails to match them. I find it more useful to think of them as obsolete. You now have more information and can see the situation more clearly.

In my experience, executives don’t usually get upset when work is going to take longer than planned. Very few milestones are deadlines on inflexible schedules that can’t be missed. What does upset executives is not knowing that things will take longer than planned.

“If you have to forecast, forecast often.”

If it disagrees with experiment, it is wrong. In that simple statement is the key to science. It does not make any difference how beautiful your guess is, it does not make any difference how smart you are, who made the guess, or what his name is – if it disagrees with experiment, it is wrong.”

Most of the estimation problems I hear complaints about are not about the estimation, but about the behavior surrounding estimation.

One option is a trap. Two options is a dilemma. Three options is a choice.

If people are behaving badly, better estimates won’t help. How can we alter our behavior so that we can work effectively in spite of the fact that our estimates will never be as accurate and precise as some people will sometimes want?

If you don’t handle the needs of the people, the organization also doesn’t work well. You cannot deal effectively with risk without acknowledging that uncertainty.