The rules of perfect estimation | Antreem
Go to blog

The rules of perfect estimation

of reading
Nicolò Sordoni
thumbnail

One of the most important activities in a project is the assessment of the timeframe and, consequently, the costs involved in its implementation. An error at this stage can have consequences that can have a significant impact on An error at this stage can have consequences that can have a major impact on the whole workflow. Although various approaches and methodologies have been defined for managing a software project, they all include an estimation phase. For this reason, it is worth paying attention to a few simple things.

1.You don’t live by code alone

Sviluppatore che stima tutti i task del progetto

One of the most common mistakes made, is considering only activities that are strictly related to development. There is nothing more wrong than thinking that the time needed to complete a task is the time needed to develop it. Besides pure development, there are a number of supporting activities that are essential to consider:

  • Architecture: before developing a task, it is good practice to invest time in analysing its impact within the application architecture.
  • Automatic tests
  • 4eyes: the 4eye phase takes up time on the part of both QA and the developer
  • Integration testing: once the task has been integrated into the project, it will be necessary to re-test all task-related sections.
  • Bugfixes: in an ideal world everything would always work on the first try, but the reality is quite different and it is important to consider that very often some small (in the best case) corrections will be needed

    2.Dive et impera

    Sviluppatore che suddividere in microtask i task

Estimating a complex or high-level task without breaking it down into smaller parts increases the risk of error and may hide unexpected pitfalls: that is why it is always advisable to break down the most burdensome tasks. It would be ideal not to have activities that require more than 4 or 5 days of development. Otherwise, there may be subtasks that have not been taken into account.

This breakdown also favours an iterative approach to development, making it easier to organise any tranches of work. In contrast, structuring a bi-weekly sprint would be much more complicated if all activities lasted more than 5 days.

The breakdown into microtasks is also extremely useful to justify high estimates: it makes the actual complexity of the project clearer to those who will have to approve it and is a sign of an accurate analysis. Sometimes this can make the difference between an opportunity lost and one gained.

3. Learn from your mistakes

Sviluppatore che ripensa agli errori commessi per migliorare

In order to progressively improve one’s ability to make correct estimates, it is important to carry out a retrospective analysis at the end of each project in order to understand what the main errors were in the analysis phases and what was not properly considered.

Such an analysis, however, needs data to support it. It is therefore advisable, for each of the estimated tasks and for each activity not initially considered, to report the estimated hours and the hours actually spent. Keeping this register updated on a daily basis also allows for better project governance.

4. Think negative

Sviluppatore che pensa al worst case scenario di un progetto

Programmers are optimistic people by vocation, with an innate belief in their own abilities and in StackOverflow. This leads to a tendency to underestimate the risk when assessing a task with unknowns.
It is important to assess all possible complications related to a feature in order to have an idea of how long the worst case scenario would take, then make an intermediate assessment between this and the “average” case, using one of the appropriate techniques (e.g. Planning poker).

5. No going backwards

It may happen that some assessments may be considered excessive by the client, but it is important to remember that lowering the timeframe without justification appears unprofessional and risks losing credibility. Instead, it is advisable to negotiate which functionalities should be removed or postponed to a later stage.

6. A positive error is still an error

illustration of two people speaking about the project

A “positive” estimation error may occur, i.e. taking less time than estimated. Although this is an indicator that the team has worked well, it must be borne in mind that it is still an error that could have jeopardised the start of the project.

7. Know your team

Team di sviluppatori che collabora

In particularly dynamic contexts it is likely that in the very early stages of a project start-up the team is not entirely known in advance. It is important to be aware that this constitutes a risk.
Although we know all the members of the team in advance, it is still impossible to get everyone to agree, as everyone has their own experience and sensitivity when it comes to estimates. For this purpose, it is advisable to use the same tools as those mentioned in point 4.

Conclusions

The above points are only some of the aspects and steps to be considered in order to make a good estimate; it is good practice to define one’s own processes, both at personal and team level, and to constantly try to refine and strengthen them. This will lead to a gradual improvement in results and greater precision in their analysis capacity, which will bring, for the reasons given at the beginning, important benefits both for individual projects and for the company itself.

Nicolò Sordoni
Written by
Nicolò Sordoni

IT and programming passionate since childhood, recently has mainly worked on mobile technologies. In the last years has been teaching assistant of the Bologna University's "Mobile Web Design" course. Balance the hours spent in front of the screen with its passion for football and sports