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.

Comments (5)

  1. Abhishek - Reply

    February 26, 2009 at 6:16 am

    Hey Marco. This was a wonderful read.

    I was waiting for such a blog specially from people like you having so rich experience in handling relatively big agile teams as scrum master.

    I feel this approach is wonderful, however, it has a prerequisite that the entire team is well versed with the project and the codebase. For frequently changing teams, and teams with new members, I feel planning poker gives a much better opportunity to brainstorm on each story.

    But as you pointed out, that frequently leads to the loss of focus as regards to relative estimation.

    A very refreshing blog indeed!

  2. Marco Mulder - Reply

    February 26, 2009 at 9:16 am

    Hi Abhishek,

    Thanks for your positive comment! I fully agree with you that planning poker is a great way of doing estimations. In my experience, if there is not a big list of stories to estimate or the estimation session is only done by two or three people, it is definitely the preferred approach. Only if there are many people in an estimation session where many user stories need to be estimated, planning poker easily gets out of hand.

  3. Sjors Grijpink - Reply

    February 26, 2009 at 10:54 am

    Hi Marco,

    Very inspiring blog!

    The method you propose really emphasizes on relative estimating. I can imagine that this way the planning meeting goes much faster without giving in on quality.

    I hope to try it out soon!

  4. Andreas Ebbert-Karroum - Reply

    March 10, 2009 at 1:15 am

    Hi,

    this is a nice idea to ensure that relation between stories stays the same and the scale does not change over time. I do see a risk, as you also pointed out, that discussion suffers and not everybody's opinion is heard.

    How do you start this? Do you lay all of the stories on the table at the same time. Or do you add one by one, discuss it and if the team feels ready to estimate it, do a bubble sort. I could imagine, a fun way to bubble sort the story would be to move it up the complexity line, team members have green and red cards. Green = needs to go up; Red = already too high. You place the story, when there's an equal number of red and green cards.

    Well, just a crazy idea.

  5. Daniel - Reply

    March 18, 2016 at 7:21 pm

    In our team we had very long conversations about the complexity of user stories still final estimates seemed quite arbitrary. We tried different things to improve, indeed Planning Poker worked us the best.

    In the end we built a tool, Scrum Poker for JIRA. Poker cards for estimation in iOS and Android apps, points saved to JIRA. Free to try. Would love to hear your feedback.
    https://marketplace.atlassian.com/plugins/com.sf.jira.scrumpoker/server/overview

Add a Comment