DEV Community

Cover image for Step by step estimation guide
Mati Andreas
Mati Andreas

Posted on

Step by step estimation guide

Why this article

At some point, as a developer, each one of us has had to estimate something. Sometimes estimation is easy, sometimes hard. Easy when you know and hard when there is a lot of unknowns. And it does not matter if you are already using PERT or voting for #NoEstimates.

With this article, I want to give a simple step-by-step guide to those who are just starting or struggling with it.

But note! This document bases on subjective personal experiences. Figures are exemplary and depend highly on a "bunch of work" to be estimated.

Preliminary estimation

A project manager, team lead, architect, etc., walk to you (or slacks, emails, zooms) and ask for an estimation.

1) Take a deep breath, move your mind off from current work and make a preliminary estimation

  • an hour,
  • a day,
  • a week,
  • a month,
  • much more.

2) Make yourself and the person who requests the estimation aware of the preliminary estimation and therefore the inaccuracy of the assessment:

b) magnitude 1 hour:

  • 30 seconds spent - preliminary estimation,
  • 5 minutes spent - estimation;

c) magnitude 100 hours:

  • 5 minutes spent - black magic,
  • 1 hour spent - preliminary estimation,
  • 10 hours spent - estimation.

3) Consult with the estimation questioner about the need to spend more time for preliminary estimation or/and estimation.

4) Make a list of key points based on that black magic / preliminary estimation - a technical specification skeleton.

In my opinion, estimation makes us faster developers by forcing us to compose functionality beforehand in our minds - technical specification - thus spearing time in the future, otherwise spending of false keystrokes.

Estimation

The estimation questioner has confirmed preliminary extra time to be spent on getting a more detailed estimation.

Finish the technical specification:

  • magnitude 1 hour - 2-3 sentences;
  • magnitude 100 hours - at least two documents:
    • to client - adjusted functional requirements,
    • to developer - technical specification.

Adjusted functional requirements are a mirrored-back and specified explanation to a customer about this "bunch of work" outcome.
Estimation must also include testing, documentation, and communication!

Work

Follow the technical specification given in the estimation stage.
If you can't follow it or it does not seem complete, notify the estimation questioner ASAP, and then you can decide together either to move back to the estimation stage or not. Similarly, when bugs are reported back by any party, weigh if it is a missing initially planned feature or new feature request.

Top comments (0)