Estimating a product backlog more effectively
Ever since I read Mike Cohn's book Agile Estimating and Planning, it has been a great help in doing Agile projects. One of the ideas that I like very much is to estimate user stories on a product backlog in an abstract measure: story points. Story point estimates only need to be correct relative to each other. Having such estimates allow you to monitor velocity: how many story points can be done in an iteration. Based on velocity and an estimated product backlog, decisions about scope, schedule and budget can be made and continuously refined a very informed way.
The most common way to estimate user stories on a product backlog is by doing a planning poker session. However, in my experience it is pretty hard for a team to do this effectively for a big list of user stories. Therefore I tried out another approach.
While going through a big list of user stories in a planning poker session, team members generally try to find out as much detail as possible about every user story. For each single user story, team members often don't feel confident about making an estimate unless they have in depth knowledge. Because of this, focus is too much on being precise and not enough on being complete. Such estimation sessions need a lot of moderation to produce a fully estimated backlog in a reasonable amount of time. Also, while going through the list, it is hard to ensure that estimates are correct relative to each other. This requires to repetitively compare user stories with stories that have already been estimated while going though the list.
Recently, I have successfully tried another approach: Put every user story on it's own piece of paper and let the team order them on a horizontal scale. This was done right after the product owner had given an overview of the user stories. This approach has two advantages:
- It makes more explicit that the estimation session is about estimating relative sizes.
- Team focus is more oriented to the whole list at the same time.
I was amazed by how quick an initial ordering was made. While this was in progress, some of the usual discussions about user stories took place and some splitting and grouping of user stories was done, but much more from a holistic point of view than with a sequential approach. To be sure that we all felt that the ordering was right, we still went sequentially through the user stories (low to high) after an initial ordering was made. This triggered some more discussions and improved the ordering, but for most stories consensus about its place on the scale was reached quickly.
Once the order was right, assigning story points to the user stories was a matter of drawing lines between groups of user stories on the scale. After that some quick triangulations were done to ensure that story point estimates were correct relative to each other.
Compared to planning poker, the main disadvantage of this approach is that it helps less in balancing different views of team members. Therefore, I think this approach is mostly preferable in situations where there are many stories to be estimated and/or when team members have no prior experience in estimating relative sizes.