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
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
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
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
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
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
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.
