Estimate better - lessons from my failures
August 10, 2020
This blog post is also available as a video. If you prefer that format over reading, then check it out.
We often hear that estimating software projects is hard. Just like all the other development processes, we must iterate, learn from mistakes & improve our estimates. Ignoring the problem is only going to make it worse.
Why are we talking about this?
After getting a recent estimate wrong by a significant margin, I started thinking about ways to improve my estimation skills. Luckily for me, I recently started reading The Pragmatic Programmer by David Thomas. The book takes an in-depth look at the estimation process and the challenges that come with it. This blog post combines knowledge from that book with my own experience.
Control the perception
In the book, the author presents an interesting viewpoint about the units of estimation. The units you use can make a difference in the interpretation of the results. For example, if you tell someone a project will take 60 days, that implies a higher degree of accuracy than saying about two months. Find out the level of accuracy the consumer of the estimate is looking for and pick the appropriate unit.
Think about the scope
Build a mental model containing a very rough picture of how the system may be implemented. This may surface underlying patterns & problems. It might show alternate solutions or gaps in requirements. The model you build will introduce inaccuracies in the system. This is to be expected.
Break it down
Break the task into subtasks so that it’s easy to estimate individually. You will not get the estimates correct for every single sub-task. The key here is to determine the high-risk items and concentrate on getting them right.
Track your estimates
The author of the book recommends tracking estimates. When an estimate is wrong, don’t ignore it. Identify where mistakes were made & learn from them. I have incorporated this into my workflow as I believe this will add accountability & provide opportunities for improvement.
What is the best way to estimate?
We’ve talked about various things that might improve your estimates so far. But which method should you follow? The book gives us a few ways to approach estimating schedules.
PERT
PERT stands for Program Evaluation Review Technique - a technique used by the US Navy when planning for the Polaris submarine project. Every PERT task has an optimistic, a most likely, and a pessimistic estimate.
Using a range of values like this is a great way to avoid one of the most common causes of estimation error: padding a number because you are unsure.
Eating the elephant
Initially, we only have a vague idea of how long a project will take. Work on coding & testing initial functionality. After that, refine your estimate. The refinement gets better and better as you gain more experience in the project. As you can imagine, this approach may not fly with management. You will have to help them understand that by following this process, you will give them the most accurate estimate you can.
Eat the elephant: one bite at a time.
My takeaways
My team & I have decided to start tracking our estimates. This practice will provide insights into the progression of our estimation skills as a team.
We will also be regularly reviewing the estimates. As projects are being worked on requirements change, unexpected issues come up. By adjusting the estimate, we are providing a more accurate depiction of the current state of things.
I highly recommend the book The Pragmatic Programmer. It is amongst the best programming books I have ever read.
What are some of your tips about estimating software projects? Feel free to drop a comment or reach out to me on twitter.
