Swimlane Sizing – Complete & Fast Backlog Estimation

Reading time ~ 5 minutes

Thanks to Adrian Wible for sharing this tip when I was in Nevada a couple of years ago. It’s now one of the most powerful simple tools I have at my disposal. I use it frequently with teams to rapidly size their backlogs and recalibrate their sizing.

This can be used with teams at any experience level but works with least pain if teams aren’t used to story points beforehand.

Teams new to story-points (or even working together) often get hung up on the numbers themselves and instinctively want to start converting to hours, ideal days, elapsed days or similar. The value of story points for teams during estimation sessions is in the relative sizing, not the actual size.

This approach keeps numbers entirely out of the mix until the end and allows participants to focus solely on the relative sizing of stories.

Once we’re over the relative sizing hurdle, adding numbers becomes a straightforward activity.

I’ve done this same activity with electronic tools but I’ll describe the manual version here…

Preparation:

Get your deck of incomplete user stories on readable cards or stickies.

If you also have a couple you have completed, these are useful triangulation points but not mandatory

In a room with your team, get yourself a large flat clear surface. I recommend tabletops in the middle of a space as you can swarm your whole team around all sides – this isn’t so simple with a wall.

Using string or sticky tape mark out 8 “swim-lanes” on the table (Requires 7 lines)

Your table should look something like this.blank table

Don’t put any labels on the swim lanes

 

 

 

 

Activity:

Divide the deck of stories amongst your team and ask members to spend a maximum of 5 minutes silently placing their stories in the swim lanes – with stories of increasing size from left to right.  E.g. smallest stories in the left-most lane.

You might want to lead the team through the first 1 or 2 random stories to give them some anchors or triangulation points to work from.

Don’t say anything about story points or numbers, if anyone asks just reiterate we’re looking for size relative only to each other.

If needed; guidance on complete unknown stories at this point should be to assume they are “very large”. The next round of sequencing will allow others to move them if they feel confident in doing so.

Once all stories are placed, you’ll probably have some “clumping” of stories, as in the table here. (assume X’s are story cards).

Give the team 5-10 minutes to again silently move any stories to different lanes where they feel their size relative to others makes them more closely aligned to those in another lane (stories must be wholly in a single lane – no overlaps).

Encourage team members to quickly look at and consider the location of each story on the table.

A team may occasionally find a deadlock where a story is “stuck” moving back & forth between lanes, you may intervene, pull the card out for discussion or allow the time boxing to encourage the card into a single location. Generally if there’s uncertainty, I choose the larger option but the last step of the process will resolve these.

Your table should now look something like the example here.

Once all the cards are placed and reviewed, ask the team to rate their satisfaction/confidence on the relative sizing and placement of the cards (use a scale of 1-5). For any team members indicating a low satisfaction level (1 or 2), ask them to describe their concern and for the team to decide upon how to act (either move a card or validate its current position). Time box this to 2 minutes per team member if possible. Use this opportunity to re-place any deadlocked stories – if a team really can’t decide, be cautious and go for the larger option.

Once relative sizing is agreed with a reasonable level of confidence for the whole team it’s time for a couple more questions.

For all the stories in the left-most column, do you think you’ll be working on anything smaller?

If the answer is “yes”, call this column 3 or 5; if the answer is “no”, call this column 1 or 2 (a single number from these options – use your judgement and instinct).

Now assign remaining numbers across the top of the columns using a subset of the common modified Fibonacci sequence used for story point estimation: (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, !/?)

This will give you a table of stories much like one of the following…

 

 

 

 

 

 

(I usually prefer the far-right column remains unsized to be broken down further to make it clear that this is a coarse exercise and cannot be used for commitments).

That’s it! You’ve just estimated & sized (using story points) your backlog in well under an hour.

It’s coarse, quick and dirty but chances are that even when you learn more, most of these won’t change relative to those in other columns .

More Depth:

The use of “silent sorting” is a powerful practice for agile teams. It removes debate and ensures focused thinking however in this example its use coupled with the lack of numbers is to avoid a common problem with inexperienced estimation teams during planning poker exercises known as “anchoring”. This is where an individual on a team will speak up with their view on what size a story should be before the remainder of the team have selected their view on size therefore influencing and anchoring all others estimates for the same story to a given point.

If you reuse this approach for additional rounds of backlog items I recommend preserving some of the older stories in the swim lanes to provide triangulation points for newer stories. Without these anchors your team’s velocity and estimation may see large shifts and greater unpredictability based on the shape of the new backlog.

Teams will quickly get used to which numbers match which lanes. This practice is still valuable however you may need to encourage teams to remain focused on relative sizes and not the numbers.

I generally hold the following views (and have found these actually do transfer well across teams)

  • 5 is typically a “medium” sized story for a sprint
  • Anything greater than 8-13 requires further decomposition
  • Seriously consider also decomposing stories of size 8-13
  • Anything greater than 20 is in reality an unknown needing further investigation and decomposition before it can be sized sensibly.

These views can in themselves anchor others’ estimates towards some specific numbers. As a facilitator an awareness of the range of numbers used and their meanings is useful but be cautious that this information does not influence the outcome of the team’s process.

Update: March 2015 – 4 years after posting this article it’s still the second-most viewed page on the site. I’ve now added a second article offering some more theory to help explain how swim lanes and story points hang together with traditional estimation concepts.

12 thoughts on “Swimlane Sizing – Complete & Fast Backlog Estimation

  1. Pingback: Pedro Newsletter 04.07.2011 « Pragmatic Programmer Issues – pietrowski.info

  2. A thing of simple beauty.
    Used this with a team who were struggling with an unsized backlog but a hard delivery date. The team were able to size all the day one “must have” stories in 45 minutes. They now have enough to be able to go back to their ‘in denial’ programme manager and business stakeholders and demonstrate why the current launch isn’t going to happen.
    The team had never used planning poker before and this technique worked beautifully.
    Thanks Captain!

  3. Richard! Now there’s a surname that’s hard to forget and one I’ve not heard since 1998! – Really glad it helped – even in returning a difficult message.
    Great to hear from you 🙂

  4. Brilliant. And I agree most teams do get initially hung up on the numbers. Thanks I will use this often.

    Brett

  5. Amazing technique. However, we are a geographically distributed team. Could you point me to any online tools which support this.

    Best Regards,
    Sweta

    • Hi Sweta. In my previous company we implemented a custom drag & drop interface to our ALM tool that allowed us to perform swimlane estimating directly in the tool. We shared what we were doing live online.
      Over the last year I’ve been working with co-located teams so I’ve not needed to look more recently to see if there’s anything on the market that does this. From a quick search just now, it looks like Rally users can get this as an add-on at http://developer.rallydev.com/help/estimation-board-app I’m not sure if other ALM vendors offer the similar – I’d assume they do so if you find what you’re looking for it’d be great to see it.
      I wondered about doing something stand-alone however the challenge with writing a stand-alone app would be writing the story card data in the first place – this is dependent on what format your data is already in.
      What other electronic tools are you using at the moment for managing stories?

      Thanks for reading!
      C

      • A quick update. thanks to Jason Yip ( @jchyip ) I found Ailiasaria’s scrumblr app this morning. It’s not fully matured yet (or at least there’s a few issues in IE8).
        This is an online real-time scrum board where you can define your own swimlanes etc. No complex business rules – just straight board.
        Here’s a swimlane estimation example I threw together in a couple of minutes of exploring…
        http://scrumblr.ca/Captain%20Crom

        • More than a decade later – I’m stil using this technique with teams. With Covid, many people being distributed and so many technology advances since I wrote this post, we now run these sessions online using Miro (or similar) and a teams/meet/zoom call 🙂

  6. Thanks for this!

    I have been looking for a good technique for quickly sizing a complete backlog.

    I tried this out about a year ago and have been using it ever since. I use it on different projects, with different customers and it always works like a charm. It’s quick and dirty but thats exactly how it should be. Sizing 200 stories within an hour is perfectly doable. We did around 500 in about 90 minutes.

    Also for recalibrating purposes this works really well.

    Thanks for sharing, I’ll be spreading the word.

    Niek

  7. Pingback: 3 Steps to Valuable Reference User Stories | Stefan Wunder's Blog

  8. Excellent idea! I manage a virtual team remotely scattered and sizing-estimation can be drudgery at times…. I’m using this weapon as we plan our next iteration.

  9. Pingback: On Story Points and Distributions | The Agile Pirate

Leave a Reply

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