One of my weak spots as a developer are estimations. I simply cannot estimate how long a software developing task will take. In this article, I write about how I came up with an estimation to a bundle of tasks, how accurate it was and what I took away from it.
The software system I’m working on in the last three months is a pretty heavy legacy system. The architecture is not documented at all, there are absolutely no unit tests and it’s in general a great learning and refactoring place (no sarcasm here). The task given to me was to change five panels of this application. Before getting on the code, I had to estimate how long that will take.
Method of Estimation
My first step was to identify the tasks I needed to do in each of the panels. After that, I ordered these tasks in their processing sequence and created five work-breakdown-structures (one for every panel). This structure helped me getting a feeling how each of the panels had to change. I estimated three durations to finish all tasks for a panel:
- best case - If everything will be absolutely fine, how long will it take?
- worst case - If all goes wrong, how long will it take?
- realistic estimation - How long do I really think it’s going to take?
Using the three point estimation, I calculated one estimation with a certainty of 80% for each of the five panels:
| Panel | Best Case | Worst Case | Realistic | 80% Certainty |
|---|---|---|---|---|
| 1 | 5 | 20 | 15 | 16 |
| 2 | 2 | 5 | 3 | 4 |
| 3 | 1 | 4 | 2 | 3 |
| 4 | 1 | 5 | 3 | 4 |
| 5 | 1 | 4 | 2 | 3 |
| all | 10 | 38 | 25 | 30 |
I communicated the overall sum of 30 days to my team leader. He knows the system I’m working on a great deal longer than me. He made an estimation of 10 days max. So, right at the beginning, my estimation seemed a little bit off.
Iterative estimations
My goal for the task was not only to deal with the five panels, but also to enhance my estimations. Therefore, I tracked the time needed for each panel very carefully. After finishing the work on one panel, I corrected my estimation for the rest of the work, depending on the offset between my initial estimation and the time needed. This is the result:
| Panel | 80% Certainty (Days) | Time Needed (Days) | Multiplicator to Initial Estimation | New Time Needed for Rest of the Panels |
|---|---|---|---|---|
| 1 | 3 | 1 | 0.3 | 27 x 0.3 = 8.1 |
| 2 | 4 | 1 | 0.25 | 23 x 0.275 = 6.325 |
| 3 | 3 | 0.75 | 0.25 | 20 x 0.26 = 5.3 |
| 4 | 4 | 1 | 0.25 | 16 x 0.26 = 4.16 |
| 5 | 16 | 4.25 | 0.26 |
Lessons learned
As you can see, I needed only 8 instead of 30 days for the task. This is no small deviation and I’m sure my team leader will always smile a little when I give an estimation in the future. Of course, I want to know why I have been this far off, so I thought about it and came up with the following reasons:
- I implied a very high risk within the estimated numbers. For example, I knew that I will not need two days for the first panel. But I also feared that I could be trapped in some weird class hierarchy or will have to refactor something. Hence, I implicitly raised my estimation. I should have made that explicit, for example by adding my low level of experience with the system as a fourth value to my estimation. (I only worked for three months within this project)
- I added time for sideshow tasks like documentation or refactoring because I know there isn’t any documentation around and the code is pretty bad in some places. I also should have made that explicit
- While I was working on the very last panel, the task has been modified. One of the features of the system is to generate a Flash-report. Some data for that report gets entered via one of the panels. Hence, changes there forced changing the report. At first, we planned to adapt the report. That would’ve been quite complex. However, this plan was cancelled during the time I implemented the canges. The vanished task took a lot of workload off. Hence, I finished even earlier than expected.
Another important takeaway is transparency. I often hear developers talking negatively about estimations because they tend to be off quite a bit (like mine) or that not all factors are taken in account. The only way of getting good estimations (whatever this is) is transparency. Talk to involved developers, talk to the stakeholders, talk to more experienced coworkers to sharpen the estimation method and become more confident with your gut feeling.