Story Sizing: A better start than planning poker

By Chris Sims

I've helped several teams adopt the practice of planning poker. It's a good and useful practice, but it’s about as beginner-friendly as Badugi.

The problem is that planning poker is a lot about numbers: “Is this feature a '5' an '8' or maybe a ‘13’?” New teams have no reference for what these values mean, and it leads to confusion. As they try to figure out 'how big' a story point is, teams frequently give in to the temptation to map a story point to some unit of time. I've heard: “Let's have our 'story points' be the same as days!” or “How many hours should a 3 point story take to complete?”

So what are story points, if not units of time? They are units of work. We count them and size them precisely because we don't know how long it takes to complete a point's worth of work until we have history and data that we can measure. This measured rate is referred to as the team's velocity.

Here is a super-useful technique for bootstrapping the sizing process. Steve Bockman taught me this approach, and I have used it with new teams ever since:

Start with a pile of stories, each written on an index card or sticky note. Have the team identify one story that is of roughly “average” size, not one of the biggest stories, nor one of the smallest.

Now find a wall that’s long enough to line all of the stories up from left to right in a single row. Take the “average” story and stick it on the wall, right in the middle. Pick up a second story—any one will do—and if it’s bigger, stick it to the right side, and if it’s smaller, stick it to the left. Keep doing this with each story, swapping them around and putting them in size order, until you’ve got them lined up like the Von Trapp Family Singers, smallest to largest.

This process usually involves some interesting discussions, and stories will tend to move about until the team is happy with the ordering. Sometimes you’ll identify a story that needs to be broken down into smaller stories, or find one that must be rewritten in order to be sized. All of this discussion is valuable; the team is learning and sharing important information. Still, in order to keep the process moving along, stop the discussion as soon as you’ve decided on a story’s rank. It's time to pick up another story card and find its place on the wall. It really helps to have someone acting as facilitator, to keep the process moving. Yes, you can hire me. ;-)

Once the stories are ordered, start at the far left and ask: “Is this the smallest story we’re realistically going to encounter?” If the answer is yes, mark that story as a 'one'; its size (or estimate) is one story point. When I’m facilitating this exercise, I start walking down the wall and have the team stop me when I reach a story that seems about twice the size of our one-point story. I stick a vertical stripe of blue tape just before it, to mark off where the one-point bucket ends and the two-point bucket begins. Similarly, I get the team to identify where the three-point stories start (they are three times as big as our smallest story), and so on.

I like to use Fibonacci numbers for story sizes, because they grow at about the same rate at which we humans can perceive meaningful changes in magnitude. Using this sequence, you can divide the rest of your wall into buckets of stories sized: 1, 2, 3, 5, 8, 13, and so on.

This approach to story sizing gets a team up-and-running. You won't get bogged down in philosophical discussions about the meaning of a 'story point', or whether or not a story point has a Buddha nature. It's expedient, engaging, and yes, even fun.

Try it out, and let me know how it works for you.

Cheers,

Chris

Comments

[Gerry Kirk]

Chris, I've found this technique much better than planning poker for a large batch of stories, even with teams that understand planning poker. One team new to story point estimation estimated about 50 stories averaging 2-3 minutes a story - amazing!

For assigning numbers to stories, I like to keep 1s and sometimes 2s for later in the project, when you get those small enhancement stories that require little work. At the start of a project, stories are usually bigger than that.