Estimating a product backlog more effectively

25 Feb, 2009
Xebia Background Header Wave

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, so how much load is realistic within an iteration? Consequently, you can have an outlook with an estimated product backlog. While decisions about scope, schedule, and budget can be made and continuously refined in 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.

My learning journey to get estimates effectively without planning poker

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, the 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 repetitively comparing user stories with stories that have already been estimated while going through the list.

Pivoting the estimation process to gain speed and completeness

Recently, I have successfully tried another approach. Put every user story on its 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 it 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 quickly an initial order 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 were 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 order 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 the different views of team members. Therefore, I think this approach is preferable in situations where there are many stories to be estimated and/or when team members have no prior experience in estimating relative sizes.


Get in touch with us to learn more about the subject and related solutions

Explore related posts