Why it matters?Permalink

Devs estimate work constantly.

Being good at it makes us reliable and helps our careers. Estimating is tricky, and we’ll never get it perfect, but we can get better at it and arrive at reasonable estimates most of the time.

So, how to estimate?

1. Understand what we’re buildingPermalink

The first step is to know in great detail the expected output of our work. Go deep. Get to the bottom of the thing we are about to estimate.

The output should be a list of things to do (or steps to destination).

Think about:

• Context, why we’re doing this?
• How exactly should this work?
• How it should look? (if UI)
• What are the input data?
• What should be output data?
• Performance expectations
• Edge cases
• Documentation needs
• Tests
• Deployment
• Dependencies

Only after we thoroughly understand what we're building can we estimate.

Now, we use our experience & gut feeling to estimate how much time a task will take.

Yes, we pull it up from our sleeves. If our estimate is in days, weeks or even months, it's wrong. Why? Because we’re never going to be able to estimate task which lasts longer than few hours with any meaningful precision.

2. Break it downPermalink

We must break the work into smaller parts if our estimate is more than a day. (We can use our list from the first step.)

Then we need to estimate new smaller tasks separately.

If any of those are still over 8 hours, we need to break it down further until we have lists of tasks where none of them is more than 8 hours.Then we sum it all up, and we'll have our estimation of the original task.

This breaking of tasks into smaller tasks will produce more precise estimations for two reasons:

• A. It helps us to think through (again) what we need to do to finish the task.

  Breaking things into smaller parts reveals more details about what we need to do. It is time to think about it when we estimate, not only after we’ve started implementation.

• B. Our estimate is much more precise for smaller timeframes.

  A bigger timeframe means more noise and so less precise estimation. If our brains think in hours & very concrete steps, they can still come up with reasonable estimates. Anything on a bigger scale is blind guessing.

The longer the estimation, the less precise it is, even if in hours.

To solve this, we increase the step size.

We can use Fibonacci numbers: 1, 2, 3, 5, 8 or power of two: 1, 2, 4, 8. We can estimate if a task is an hour or two, but can we really estimate whether it's 6 or 7?

3. Add bufferPermalink

So we have broken tasks into small pieces and estimated each one.

Now we can sum it up. But we’re not done yet. We add 50% on top of that. Why? Because people really suck at estimations.

We always forget things, and our gut feeling is way too optimistic.

Where did I get a 50% buffer?

Experience. It’s the number that works for me most of the time. Your buffer number might be lower or higher, and you should adjust it if you see you’re overestimating or underestimating too often.

Start with 50% and adjust.

SummaryPermalink

• Understand in great detail what you're building

• Break it into smaller tasks so no task is more then 8 hours

• Add 50% buffer because people suck at estimations

Happy coding (or estimating?)

You might also like