Have you ever faced prioritizing a long list of stories or requirements and thought, «This is going to take forever!» I have, and so I was thrilled to learn a technique at XP2011 that helps with this dilemma.

I had a chance last week to apply «Silent Grouping» with a client, and since I found it to be a very positive experience I would like to share it with you here. Ken Power led a session on «Using Silent Grouping to Size User Stories», and even though I missed that session I did get to read about it in the conference proceedings.  You can also read his detailed post on the technique at his blog System Agility.

First some background…

I’m working with my current client on some greenfield development, and we spent some time last week working on a list of high level features and stories for the system. At the preference of my client, we were doing this in an excel spreadsheet. We came up with 45 stories.

This list of stories is going to feed into some documentation that must be prepared for higher-ups (ie, documents with a strong potential of becoming «shelfware»). But the list was also important to the tech team as a way to start solidifying our vision for the system.

After loosely defining the 45 stories, we agreed to rank them based on priority, level of effort, and technical risk. I suggested these categories because I know it’s unlikely we will get to many of these features for a long time, if at all. In addition to feeding the spreadsheet to higher-ups, I also intend to use it to encourage the team to focus on those things which are most important to the customer or which we believe to be risky enough that we need to tackle that feature early on.

My client wanted to just go down the list in the excel spreadsheet and discuss each item. However, my eyes were already beginning to glaze over and I knew that my odds of paying attention the whole time were low. Here’s the precise mathematical «proof»:

My ability to focus = 1 / (Time this will take) = 1 / (45 stories * 3 rankings * 5 minutes minimum per discussion) = 0.15% chance that I will stay awake

Since the odds were stacked against me staying awake, I successfully encouraged the client to let me print all the stories on index cards and then do a sorting game the next day.

Silent grouping allowed me to focus

Instead of spending all day discussing that spreadsheet, we sorted all 45 stories over lunch, across all three categories.  And we still managed to have a pretty casual conversation too!

A quick overview of how it worked

Here is how Ken’s «Silent Grouping» works, or at least the way that we did it:

1. Lay out cards for «buckets» on the table, or on a board. In our case we used «High Medium Low» for Priority and Risk, and «Large Medium Small» for level of effort. Ken’s paper also suggested using story points for your buckets, but in our case we didn’t feel we would get any value out of more specific buckets since our stories are currently very high level.
2. Put a stack of note cards out for all the stories. It doesn’t matter what order they are in.
3. Round 1: Each person takes a card off the stack, and silently puts it in the bucket where they believe it fits. At the end of this round, all the stories should be bucketed, and everyone has placed roughly the same number of stories. There is no talking at this point, even if you disagree with the placement of a card!
4. Round 2: The team examines the cards as a whole, and take turns moving cards between buckets as they see fit. This is where you account for differences of opinion, and those that the team doesn’t agree on should go into a «parking lot» bucket for further discussion.
5. Round 3: Any items in the parking lot are discussed by the team and then put in the agreed upon bucket.

Why it worked for us

In our case, this worked really well because I knew that we didn’t need to discuss all 45 stories. We had a large amount of agreement already on what was most important, the most risky, and the hardest to do. The silent grouping exercise confirmed that the team for the most part agreed on that already, without incurring a lot of time discussing each item.

There were some items that we had disagreements on and we had to discuss before we could place them appropriately. As in any agile estimation exercise, the discussions are often more important than the actual estimates derived. Estimates are often wrong in the long term anyways, and the discussions of «what does this mean?» or «why do you see that as hard?» are where the real value occurs.

Save time by focusing on what actually needs to be discussed

Using Ken’s silent grouping technique allowed us to quickly focus on the stories we needed to discuss the most, and not spend time on those we already agreed on.

The other big advantage of this technique was the relative speed of the exercise. A skeptic might assume that’s bad, because how accurate can your estimates or priority rankings be if you breeze through them? But if you just want rough groupings, who cares if you are off by a little bit?

At this stage of the project, we know that our stories are somewhat vague, and that there is a large degree of uncertainty around development estimates. If we went through an exercise that said «this is 100 man hours of work», then we are attributing a misleading amount of certainty to a very inherently uncertain process.

Therefore our estimates should also be uncertain and vague, by either using wide ranges (50-100 hours) or using general buckets (High/Medium/Low). And if our buckets are going to be vague, there is no point in spending a huge amount of time debating which item goes into which bucket.

Good processes maximize value

Using silent grouping, we literally are getting 80% of the value for only 20% of the effort. That allowed the team to quickly agree on a vision and prioritization, and freed us up to get back to productive coding work. That’s my definition of a good process improvement!