«

»

Mar 22

The affinity method for estimating stories

Introduction

Planning poker is quite a popular method for estimating stories, but one of the huge drawbacks on complex projects is that it takes forever, especially if you have over 20 stories.  Here is a step-by-step guide for how I guide teams through a much quicker process for estimating stories.  I have used this method with teams who have over 200 stories and we have completed the estimating session in under two hours.

When to use this method

This type of estimating is most useful at the foundations or release/delivery planning stage.  It is most useful as I have said before when there are 20+ stories to be estimated.

Pre-Requisites

It is important that before you start the estimating session that the team understands what the story means.  The estimating session will have been preceded by a number of story writing workshops where the stories were discussed with the team members, but not necessarily in great detail.  So completed story cards with preliminary discussions as well as preliminary or high-level acceptance criteria feed into this process.

Clear floor space or wall space 2-5 metres is preferable

Some cautionary notes …

If your team is new to Agile you may find “observers” turning up to the session.  These may be business analysts, product owners, project managers or whatever.  I sometimes find that these people, with best intentions, want to influence the outcome.  For instance project managers are keen to please their sponsors and want to provide estimates that are often smaller than the team feels comfortable with.  When I facilitate these sessions I make the rule that the observers may only do just that- observe.  The only people allowed to estimate are the ones who will be doing the work.  Yes, OK they may get the estimate “wrong” – in fact I can almost guarantee that they will, but the team should be encouraged to learn from their mistakes and not be held hostage to the opinions of others who will not be as committed as the team will be to getting the work done.  To this end I always recommend that the session is facilitated by an experienced Agile mentor or coach who is able to deal with the difficult characters who may unintentionally (or even sometimes intentionally) sabotage the efforts and outcomes of the team before the work has even started.

The Process

Setting up the workspace

1) The far right of the workspace indicates those stories that are the most complex or most time consuming.  The far left indicates those that are the most simple or quickest stories to complete.  I like to put markers on the board to remind people of two sides of this continuum.

Starting

2) One member of the team randomly chooses a story card from the pile of stories; they read out the story to the rest of the team.  They then place that story on the board according to how they feel about the level of complexity or time to complete.

3) The next team member then randomly selects the next story and places it either to the right or the left or in the same relative position to the previous story.  A long way to the right of the previous story suggests a very much more complex story, while one a long way to the left would indicate a much simpler or easier story to complete.  The is a relative estimating method so the distance between the stories is important.

4) This continues for a few goes until there is about five or six stories on the board.

5) Once there are a number of stories on the board team members then have a choice in how to use their turn

            a) they can either select another story and place it on the board or;

            b) they can move one of the other stories.

In the instance where the member elects to move a story they explain to the rest of the team why they believe this to be so.  The team can then discuss where is the most appropriate place for the story.  I find that it is good to keep the discussion short and if there is serious disagreement in the team then err on the side of caution and put the story further to the right.

6) The process continues until all the stories are on the board.

7) Assigning the points

The outcome should now be groups of stories spread across the board.  We then allocate story points according to the rough Fibonacci sequence as we do in planning poker – (1, 2, 3, 5, 8, 13, 20, 40 & 100) – we then write the story point value on each of the cards.

Again it is important to not get too hung up on the numbers at this stage of the estimating process as finer turned estimates will be provided as the project progresses and more is known about the product we are creating.  A good point to remember is that it is better to be roughly right rather than precisely wrong especially in the early stages of the project. However it is worthwhile just retesting our thinking with some of those stories that may have been borderline between two groups, especially those of numerical significance i.e. those the are between 20 and 40 or 40 and 100.  There is no point in “dying in a ditch” over a story is a 1 or a 2 at this point.

If you have any further questions about this technique then please feel free to ask in the meantime … happy estimating 🙂

0saves
If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

About the author

Mark Buchan

Mark is an Agile Consultant and Executive Coach who specialises in working with leadership teams when they are transforming their organisation to a more Agile way of delivery.

2 comments

  1. James Grenning

    I use a similar approach. I call it the planning poker party. Here’s the description http://www.renaissancesoftware.net/blog/archives/36

    1. Mark Buchan

      Thanks for sharing James – I look forward to reading this. Its always good to know many different ways to achieve the goal, keep it flexible – keep it agile 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site is protected by Comment SPAM Wiper.