I’m not a fan of using story points, however, one way or the other, estimates are a very important step in any project and a key to delivering on-time.  The result of not doing it is downright awful, and everybody in the team suffers the consequences.  In this post I want to share the steps we follow to make estimates.

Without further ado,

1. Get the whole team to learn what the user stories or features are all about.  It is very important that everybody in the team understands all the features that go into a sprint.  Clarify the requirements so that everybody understands in depth what they are estimating.
2. The team must include an active Product Owner, otherwise do not proceed with the estimates.
3. The Product Owner needs to answer every question the team raises.  If the team doesn’t raise any question, then there is a problem.  Keep at it until everybody understands all the stories in the same way.
4. For every feature, have the team make three estimates: best case, worst case and most likely case, in that order.  Order is important because you want to give people a chance to be their usual optimistic (best case) or pessimistic (worst case) selves.  Once they get this out of their system, there’s a better chance that they can lean back and come up with a realistic most likely estimate.  Once you have these numbers, use PERT to calculate the task’s ETA.  Normally this is calculated as (Best Case + 4*Most Likely + Worst Case)/6.  If you know from experience that the team tends to be overly optimistic or pessimistic you can change the factor to weight the calculation one way or the other.
5. Promote a participative culture in your team.  Ask, and encourage others to challenge estimates that seem out of range.  Why is the estimate so high?  Why so low?  This discussion might uncover obstacles and opportunities that would normally go unnoticed.
6. Keep cycling through the estimates until every single question that can be answered has been answered and each estimate falls has been sanity-checked by the whole team.
7. BTW, besides better estimates, this process really cements down the team’s commitment to these estimates.
8. Calculate the team’s capacity per sprint, Capacity = #team members * working hours * days in the sprint. It’s important to take into account vacations, holidays, planned personal time off, and whatever limits capacity.
9. Once capacity is calculated, then you can figure out what features really fit in the sprint.
10. To learn from your estimation process, keep track of metrics, especially deviations.  Once you have history from at least three sprints, you can use these statistics to polish future estimates.

 It is highly important that this be a commitment-driven process.  In the end, the sprint goal must be crystal clear and the whole team must be on board with it.  Given this commitment, the team will make sure that the sprint is delivered on time.