When will it be ready? How long will it take?… I am sure that these kinds of questions are familiar to many of you and you have asked or heard them on more than one occasion while working on projects.
We do not have a crystal ball to know exactly how long it will take us to do something. Until we have the crystal ball, we have to resort to giving estimations and ensuring that these are as close as possible to reality.
In this post I am going to share with you my experience to make our estimations more effective.
If you are interested, keep reading!
What are we estimating?
Before starting to estimate, it’s important to know the goal of our estimation. It’s not the same to estimate a small task than a complete project.
Sometimes a high-level estimation is more than enough, for example in the case of complete projects where it’s necessary to have an order of magnitude to know the scope in time and resources that it may take. This kind of estimation is useful for budgeting.
In the case of projects, user stories or tasks where there is a more limited scope, it’s not only easier to estimate with a higher level of detail, but it may also be necessary to plan the workload. In the case of Scrum, for example, user stories are estimated before the start of sprints, which allows the sprint workload to be leveled to what the team can actually take on.
The importance of estimating as a team
If we want our estimation to be accurate, it’s essential that the people who participate in it have the necessary know-how to be able to carry out what is intended to be done. This same approach is followed in Scrum, where estimations of user stories are done collaboratively by the people in charge of carrying them out.
A common mistake that I have seen in the past is not including developers in project estimations. The worst part came when, in addition to this, a deadline was committed to the client based on the estimation without even consulting the developers.
This not so agile approach in many cases ends up causing that, due to the need to reach the deadline and the incorrect estimation, the team ends up burdened with great pressure, compromising development quality and with fatal consequences for team health.
Therefore, my advice is to estimate by consensus, where at least the opinion of the people who are going to work on the tasks to be carried out always exists and is valued.
And the unforeseen?
When estimating, it’s important not to be too optimistic and think that everything will go smoothly without unforeseen events. An excess of optimism can cause any deviation or inconvenience that we find to blow up our estimation.
Whether for high or low level estimations, it may be interesting to include an error margin, which will be higher or lower depending on the possible unforeseen events that we detect. For example and taking it to the world of software development: possible external dependencies with other teams, incompatibilities in the integration of different components, use cases not considered, etc.
To end…
In this post I have explained some points that, based on my experience, I consider are important to ensure that the estimations we make are effective.
In the first place, we have seen how, depending on the needs, estimations can be made at a high or low level, which directly affects the time required to carry them out. On the other hand, to make our estimations more precise, we have taken into account the importance of estimating in consensus with the rest of the team and the inclusion of a margin for possible unforeseen events.
Estimating is not always easy and I am sure that many of you will take other aspects into account when estimating. I will be happy to learn from you, I encourage you to share your experiences and opinions in the comments section! 😉
