Buy a Feature - How poker chips can help with planning

Today I ran an exercise some call the "Buy a Feature" game. It's a very simple but valuable approach to brainstorming an area and building a backlog.

We had an area of our system that we realized we had let lapse over the last few years. We'd focused so much on wringing profit out of the engine that we'd lost sight of the fact that our core feature had been left behind in comparison to our competitors. For the sake of not ticking off my employer, I'll not name the feature here.

Here's an overview of how we tackled the problem:

We collected the stakeholders together into a room. This included the CEO, those tech folks with the most insight and history of this area, and the representatives/advocates of the users of this feature. I facilitated.

• Step 1 - Collection - Everyone wrote ideas (features/stories/backlog items) on an index card. They read it aloud and put it on the table for everyone to see. We did this round robin until everyone felt they had made a good list of ideas to improve this area. It helped greatly that everyone came to the meeting with a list pre-authored.
• Step 2 - Refactoring - We took a moment to look at the list and group or break up items that overlapped. We wanted to insure that items were stand-alone. We also wanted to make sure that items that would be built together (because they had to be), were prioritized together.
• Step 3 - Buy a feature - I gave everyone in the room 10 poker chips (it was a list of about 25 items) and said they could put all the chips on one item, or each chip on a different item. They should "spend" their money as they saw value.
• Note: We could debate whether everyone's money was equal (example: the CEO's?) but you'll see in the following step that this didn't turn out to matter. The goal of this exercise was to get to consensus within one hour.
  
• Step 4 - Tally and Discuss - The features with zero chips were grouped and quickly confirmed as good ideas for a future release (not right now). The features with a large pile of chips were grouped, and the team agreed that they were not worth debating since it was easy to agree that they had to be built soon regardless of cost. This simple approach kept us from discussing any of the items (cost, design, etc) where we all easily agreed on the outcome. One of the big things I see when facilitating teams is that they spend time discussing the wrong things and never get to the tough stuff.
• Step 5 - Repeat - For all the items in the middle band of votes (they were all chip piles of 2-3), I gave out another 5 chips to each person and had them spend on only those. This provided the same outcome, but only on the middle set from the first round.
• Step 6 - Close - We got really lucky. I color-coded and sorted the list in an excel spreadsheet (documenting the meeting) and asked the team if they had issues with it or supported it. Amazingly, the group agreed that the list made complete sense. I proposed that this "mini-backlog" be a project, that the top band was in, the bottom band was out, and the middle band was scoped based on the estimate that came back from high level design. Again, the group agreed and we were done with our meeting in an hour.

So... in one hour we took a team of people and tackled this problem. We came out with a release 1 backlog for the project and knew exactly where to go next. I have to say it is the quickest we've done this. Normally we spend a lot of time discussing and we run out of time before we can prioritize and agree.

What was the one thing I'd do better next time? I'd have a different color poker chip for each person so that they could move chips around if they changed their mind. People couldn't remember where they had placed, so they couldn't easily move their chips... although this could be good and bad.

Have fun with it... the tactile/physical interaction from this definitely aided the exercise.