Software engineers are often asked for a tough task: time estimates. Giving estimates is hard because there are many factors that need to be taken in account like alternative flows, waiting for dependent tasks, tests, data migration, documenting and deploying. Following a process rather than just making up random numbers can help engineers create better estimates.
I am currently working on a project at Codelitt that follows an estimation process of five phases:
1. Determine the scope
2. Build a model
3. Break the model
4. Calculate estimates based on models
5. Store estimates.
This process is based in the book The Pragmatic Programmer.
The process starts by understanding what needs to be done. Questions must be formulated to identify main flow, alternative flows, dependent tasks, documentation, etc. Even though tasks’ description may contain all the answers, it is important to establish a template to describe features in a manner that will force the team to think through different aspects and perspectives about the problem. It is always worth going through carefully the specs and figuring out if anything needs to be clarified. Good understanding of the task is a requirement for the process of building a model.
After determining the scope, the model needs to be built. This will provide a picture of the task being estimated which could be diagrams, mental models or any other tools used to build models. Doubts about the task can rise while building it, don’t hesitate to seek answers, after all it represents what needs to be done, therefore it needs to be as accurate as possible.
When the model is done, it’s time to break it down in order to estimate its components individually. Break it down into distinct items, and then break these items into smaller distinct items, and so on, until you reach the smallest component.
Do not forget about alternative flow, tests, exception handling, data migration, documentation and deploy, these are important tasks often forgotten.
After breaking the model down it is time to calculate estimates for each component identified.
Before digging into elements and assigning values for them, a unit of measurement needs to be defined, and also a minimal value that every element must have (for example, at my current project at Codelitt, the smallest amount of developer time is measured in half a day). After that, critical tasks that have the most impact on the results need to be identified. Estimates for these critical tasks must be as accurate as possible. To do such a thing is important to figure out how to justify these estimates, thus they won’t be only random numbers.
Estimates should be recorded, in this way they can tell you how close you were after the task is completed.
Stored estimations are also an important resource for futures estimation processes, even if they were wrong. If they weren’t correct, you can find out what you missed and make sure you won’t miss it again in the future.
Apart from these phases, it is also worth it to mentioning that we always do estimations with at least two different employees. This allows us to have different perspectives about the same problem.
We have had good results executing this process for estimates we are asked for. It has helped us provide better estimates.
Obviously, this process can be changed to better suit the team’s needs, so try to follow it and observe the results for possible improvements.
Download our Incubator Resources
We’re known for sharing everything!
Save more time, get more done!
Innovate from the inside
YOU MIGHT ALSO LIKE