Estimating Work

Estimating work is so crucial but is well recognised as being a bit of black magic. It's used to plan out work, ensure success and keep everyone on the same page. This post aims to break down that black magic, and bring to light some of the context surrounding estimates and things to consider when making them.

The Wording

What is more accurate, is to make an educated estimate, rather than just "an estimate". The change in wording makes it clear, that it is an informed thing, rather than a concrete, never changing thing.

The Audience

You should ask yourself for whom you are making the estimate as this will likely tell you why you are making it, so that you can include the right level of detail:

yourself - to plan out your own work relative to other work
your direct manager, who might report it on to others who report it to the business
project manager, CTO, other colleagues - to report back to the business

For example, you might want a breakdown of the estimate, that you can sum up. But a CTO may want a one word answer for how long something will take.

The Details

On the note of level of detail - a surprising number of people are simply not organised and don't have much level of detail. If you do, it is a gift. However, with such a gift, you don't always want to share a long story about the breakdown of an estimate.

If you have details, summarising them in to a word or sentence is a skill in itself also.

That Quantified Estimate

Once you have the details of an estimate, you will have to quantify them somehow, in order to then later be able to summarise it all. Different teams estimate in different ways such as assigning:

story points
t-shirt sizes like extra small, small, medium, large, extra large
amounts of time, like days or weeks

To do this, a benchmark of previous work is always useful, such as what it means for a story be 5 story points.

What is Actually in an Estimate

Usually estimates are just a measure of the "raw work" in question, and do not include overhead like:

public holidays, leave
other overhead like meetings, learning

But such overhead is crucial when mapping an estimate to an actual date that work might be finished by a team, so these things do need to be considered. The good news is that overhead is generally easier to predict than an estimate of work.

To add overhead, you could manually try to add some number of hours or days of known overhead to the estimate.

But some of the best people I know take an estimate, and simply double it before presenting it. It can be hard to defend this with reasons - but a lot of the time some multiplier, like x1.5 or x2 is used to add in both risk mitigation for the actual work, plus overhead, in order to arrive at a final date that work might be completed.

Large Estimates

Large estimates should definitely be broken down, as the higher the estimate, the bigger the margin of error, and also because work generally should not take longer than a sprint to complete, to avoid it dragging on.

How Long to Spend Estimating

An important point is that there is always a level of risk in estimating, and that we should not spend too long estimating.

The Final Educated Summarised Estimate

A final educated estimate might look sound like having a goal of delivering by the end of month including any public holidays, leave and other overhead.

Reflecting on Estimates

Back on the concept that estimating is a black art - when asking others for examples of past estimates, you may find that there are none to share which is a bit mysterious. Or you might be told to check the backlog - although, it's often impossible to tell with tickets that are done, how long something actually took.

Team retros are a good place to discuss reflections on work, or separate meetings.