Musings of ls6

Backlog Prioritization Experiment

I took the “silent grouping” technique I’ve known from working with affinity diagrams and tried the same mechanism for backlog prioritization. It worked.

Longer version

First a disclaimer: I’m describing here (yet another) method that uses “group wisdom” to bring order to a set of things to be done. There’s time and place for methods like this as there are times and places for a more structured approach. Neither is a silver bullet and your mileage may will vary :)

Now, down to business…

Suppose you have a bunch of (work) items to prioritize with respect to when you should start working on them. They don’t necessarily need to be user stories, could be on different levels of detail like an initial “shopping list” of everything that you want to have done eventually.

  1. Make all of them visible and accessible to the team: index cards on the table, stickies on the wall. A software tool may work but everybody needs to see the current status at the same time.
  2. Explain the rules:
    1. We will be putting things in order without talking. We will arrange cards in a vertical column—the higher the card in the column, the higher its priority.
      We are not necessarily assigning value, we are putting them in order we want to tackle them later.
    2. There can be no two items on the same level. If you cannot decide I’ll flip the coin—seriously, be ready to really flip the actual coin.
    3. Each person in turn will move one card at a time. You can move a card that hasn’t been prioritized yet or change the order of cards that have been sorted already. Whatever you want as long as you move only one item.
    4. You can say “pass” and skip your turn if you are happy with the ordering you see at the moment.
    5. Remember: no talking!
    6. I’ll start…

Now pick a random item and put it in somewhere around the middle of the future column.

Let them work and don’t be afraid of long pauses and silence until either:

  • everyone says “pass” which means they are done, or
  • you notice items going back and forth whcih means you should let them talk about these genuine differences.

Background story and extra thoughts

I’ve tried it today, on a hunch, first time ever with a newly formed team trying to work with an initial “shopping list” of stuff the project should deliver. It worked really well.

I didn’t stick 100% to the rules described above. Once I’ve noticed it is working and most of the items were prioritized I’ve let them add to the initial list, split items etc. but still killed all discussions until all the items were sorted. Once they were sorted there was no need for discussion :)

Basically, the silent part worked exactly as with grouping on an affinity diagram: it took surprisingly little time and we completely avoided diving into details unless it was really a contentious point. Given that the mechanism worked so similarily I bet it should work in principle. I’m definitely going to use it in the future.

I doubt it will work as an excercise when sorting an artificial list that people are not invested in.

Edit: I’ve tried it again with a different team—it worked :)
This time we have encountered the back and forth item swapping early in the process. Each time we noticed that we marked the pairs and parked them to revisit once the rest has been prioritized. The subsequent discussions were short and, in essence, were about more precise understanding of the wording (scope, really) or splitting the item into phases which then were easy to fit between other items.