Commentary on The Art of Agile Development's The Planning Game practice.

Prior to The Planning Game, the most popular approach to prioritization went by the name "MoSCoW"--for "Must Have," "Should Have," "Could Have," and "Won't Have."

Actually, that's not quite true. The most popular approach, then and now, was to say, "Everything's important. Do it all." Which obviously doesn't yield great results.

And that's problem with MoSCoW, too. People fear that MoSCoW actually stands for "maybe," "next time," "never," and "never ever." So the savvy stakeholders mark their stuff as "must have." We end up with the "do it all" approach, except that now we get to spend our time arguing over how many items can go in each category and whether something is really a "must" or not. Bleh. No thanks.

That's part of the genius of the planning game. In the planning game, you don't argue about the priority of any individual story. Everything is assumed to be important. There's just one overriding question:

How does this story compare in importance to the other stories we have?

It's a surprisingly useful distinction. You see, if you use something like MoSCoW, in order to prioritize your story ahead of Fred's story, you have to say, "Well, Fred's story is nice, but it's clearly not a must like mine is." And Fred, being human, gets all defensive and has to protect his sacred honor by explaining how his story really is important or he wouldn't have bothered wasting everyone's time with it.

In the planning game, there's only one list of stories, and the stuff at the top of the list gets done first. No ties, no "do them both at the same time"--one list. And so you end up with conversations like this: "Fred's story is clearly very important, and much more important than these stories here. But I think mine should be done first for reasons X, Y, and Z." And now you're talking about how each story compares against the others rather than dealing with abstract categories.

It's amazing how well this works. People have conversations and solve problems together rather than arguing about poorly-defined categories. It achieves results surprisingly quickly.

There are some preconditions to making this work. When I've seen the planning game fail, it's been for two reasons:

1. Failure #1: No decision-making authority. In other words, the people prioritizing are not the real decision makers. This often happens when the team is unwilling or unable to get stakeholders in the room. It kills prioritization discussions because nobody has the authority to compromise. Pissing matches result.

2. Failure #2: Relying on electronic planning tools. Electronic planning tools have their place--they're useful for coordinating distributed teams, for example--but planning sessions, especially initial planning sessions, require disagreements to be exposed and worked through. Face-to-face discussions are essential for this to go well. (A big table makes it much easier to see the whole plan, too.)

Ultimately, prioritization is about coming up with priorities that are going to make the most people happy. Or, to be slightly more realistic, the priorities that will be least disappointing to your major stakeholders. Since everybody has a different opinion about what's important, this requires getting together, talking about what you find important, working through disagreements with your peers, and finding common ground. It's a very human process, and the planning game excels at making that process work.