Estimates are the bane of software development. They are rarely 100% correct, but you can make better estimates if you follow these steps.
Keep in mind that estimates are only one aspect of making your next software project successful from the start.
Without Further Ado
- Get the whole team to learn what the user Stories are all about. It is very important that everybody in the team understands all the features that go into a Sprint. Clarify the requirements until everybody understands, in depth, what they are estimating.
- The team must include an active Product Owner, otherwise do not make with estimates.
- The Product Owner needs to answer every question the team raises. If the team doesn’t raise any question, then you have a problem. Keep at it until everybody understands all the Stories in the same way.
- Use Planning Poker to involve the whole team in making estimates. For distributed teams, you can use PlanningWith.Cards.
- Alternatively, have the team make three estimates for every Story: best case, worst case, and most likely case,in that order (i.e., ask for their most likely estimates last). You need to give people a chance to first be their usual optimistic (best case) or pessimistic (worst case) selves. Once they get this out of their system, they are in a better position to come up with a realistic most likely estimate. Once you have these numbers, you can calculate the ETA as,
(Best Case + 4 * Most Likely + Worst Case) / 6
6. 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.
7. Keep cycling through the estimates until every single question has been answered and each estimate has been sanity-checked by the whole team.
8. BTW, besides better estimates, this process really cements the team’s commitment to these estimates.
9. Calculate the team’s capacity per Sprint as,
Capacity = #team members * working hours * days in Sprint
10. It’s important to take into account vacations, holidays, personal time off, and anything else that may limit capacity (e.g., office move). And once you know the team’s Capacity, then you can figure out how much payload you can fit in a Sprint.
11. 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 very, very important that this be a commitment-driven process. The Sprint goal must be crystal clear and the whole team must be on board with it. A committed team will make sure that Sprints are delivered as promised.
As your team gets better at making accurate estimates, they’d get better at making their next software project successful.