How do you estimate a project before it has really started. You have a great idea and want to present it to your CEO. The second question will be how much is this going to cost? You have spent a couple of hours with the customer and they want to know: “Can you do this by the hard deadline we have?” Comparative (story point) estimating works well if you have broken the work down into stories. It is more difficult if the epics are very big and there are a lot of unknowns.
I recently experimented with a simple technique shared with me earlier this year by Debbie Madden. She pointed out that an estimate point is not realistic with so little data. A range is more appropriate. She then suggested for the upper range to start with an absurd number, e.g. 10 years. Then keep bringing the number down until you lose that high comfort level the project can be finished in that time period. You then repeat the process from the bottom up. It for sure cannot be done in one day. At what point am I less than 50% sure it cannot be done.
I first walked through these steps with the team for the whole project. Asking them each question which they answered privately with yes or no. You can see the results in table on the left. I then asked them to do the exercise on their own for the 6 phases we ident
ified in our very initial roadmap shown in the table on the right.
 |
 |
| There were four team members and the director of engineering partook in the experiment. In the table above you see the response for the maximum number of sprints and minimum number of sprints. Almost everyone Agreed on a range between 7 and 13 sprints (the blue Ys). | Each member of the team gave me their High and Low estimates for milestones one through four and for the MVP milestone. The answers are not as uniform. Average about 13 to 20 sprints for the team |
Lessons Learned
We will need to complete the project and do the exercise more often to know how valuable this tool really is. But we learned a few things right there and then
- There was a very high risk we could not do the project in the four sprints available to us. This triggered a discussion with the customer to go into a different direction
- Some milestones had a much bigger spread than others. (e.g the higher boundary of m4)
- The director estimated significantly lower than the team. Is the director more experienced or risk-averse? We don’t know. In my own experience we start to estimate lower when we do not have to do the job ourselves. I have seen that with colleagues and with myself when I moved to management.
We did not analyze these results in depth because in our case we had the information we needed: we needed to change the time or scope significantly.
The opinions represented in this blog are my own, and not that of my employer or the organizations that I work with.