I once had a boss who loved to say "Estimates are lies." And I feel like some developers hate estimating because they share a similar (albeit less extreme) sentiment.

I couldn't disagree more.

What is an estimate?

In the broadest sense, an estimate is

An educated guess based on past patterns of the amount of effort required to complete the desired scope of work

Educated guess

We estimate with the information that we have available. It’s not a shot in the dark.

If we don’t have a lot of information, we’re going to have an estimate with high variance. Or the estimate will be sky-high to account for the unknowns.

Both of these cases are informative.

Past patterns

We lean on our past experience to inform future estimates.

For example, we can use how long a similar task has taken us to guess how much effort a new task will take. Then we can add time for the part(s) we've never done before.

We've submitted a form with a text field to an API before. We can use that point of reference to estimate how long it would take to submit a form with a date field to the same API.

We know that dates can be tricky. So take the time it took for a text field and add a little time for any date parsing we need.

Another past pattern we can draw from is our stakeholder's behavior.

If a stakeholder always adds scope or changes requirements, we can start adding time to our estimates to make them more accurate for this particular person/group.

Amount of effort

Philosophically, an estimate doesn’t have to be related to time.

We can estimate pure effort such as when we do story points. Story points rate the relative effort of work in a Fibonacci-like format: 0, 1, 2, 3, 5, 8, etc.

We can also do traditional person time estimates.

Person time (or man-hours) is the full number of hours a task might take someone.

But, person time and calendar time don’t always line up, particularly when we’re pairing. When 2 people are coding together, they don't go twice as fast.

I tend to use effort estimates for sprint estimates but person time for project and SOW (statement of work) estimates.

Product companies can rely on effort estimates more than consulting companies. They have different revenue streams (which we can get into if you want but is a whole other topic).

Desired scope of work

Finally, we need to think about everything we need to do to get the desired outcome. We need to account for all the “plumbing”.

For example, include all the work needed to show the button on the screen with the various user interactions and states (active, hover, disabled, focused, etc.), not just the hours to put a button in the markup.

Estimating software work isn't about nailing down exact numbers, but rather taking educated guesses based on what we've seen before.

Estimates help us ride the unpredictable waves of development, making our projects smoother, our expectations more realistic, and our teams more adaptable.