The Must Have Game
Have you ever heard people say:
"Everthing is important".
"Everything us a must".
"We had to drop all the should haves and could haves, we only have must haves left"
​
Someone clearly did not understand what MoSCoW is about. Only having must haves is one of the misconceptions about the MoSCoW principle I experienced. And that's exactly what inspired me to develop "The Must Have Game": a game to learn how to properly apply the MoSCoW principle and have people experience in a safe environment what the consequence is of statements like the ones above.
​
It is a game with cards that you play in 3 rounds. The aim is to create the highest possible revenue with the given capacity. Revenue is determined by the business value and the MoSCoW value of the backlog item:
-
Must have: revenue = business value x 2
-
Should have: revenue = business value
-
Could have: revenue = business value : 2
-
Won't have: revenue = 0
​
Round 1
The first round the participants start with what they (think they) know about the MoSCoW principle and the fact that they need to maximize revenue, with the given monetization of the backlog items as mentioned above. So what would they most likely do? There is a high chance that they select only Must Have backlog items, because they offer the highest revenue. So they put the cards ordered according to their priorities: from the highest priority to the lowest. And then the fun really starts...
​
Cards have 2 sides and until now they have only seen the front of the cards. The front contains estimated effort. Now, during implementation a lot can happen: some backlog items may have been underestimated, whereas other where overestimated. That why we often call it "guestimates": estimating is no exact science. So when they flip the cards, the real effort is revealed:
Front of the story card
Back of the story card
According to their priorities, the participants now need to calculate the revenue, until they reach the maximum available capacity. And here comes the tricky part for them: if there are still must have cards left that could not be implemented with the given capacity, their revenue is 0! Nothing at all. Why? Because a must have is a backlog item that is indispensable: the system has no value at all without these backlog items.
Round 2
Now is a good time to explain what MoSCoW really is about, as documented by DSDM. So with these new insights, you can start round 2: the same exercise, maximizing revenue, but with the right proportions of must haves, should haves and could haves.
Now it is less likely that participants will have 0 revenue, because some must haves were not implemented.
Round 3
Until now only user stories were in scope of the exercise. Round 3 brings features into play... Here the idea is that people have to select features, again according to their available capacity, with the goal to maximize revenue. Again these cards have a front and a back:
Front of the feature card
Back of the feature card
The goal of this round is to experience that a must have feature refined to its user stories does not automatically result in all must have user stories. Some may be must haves, others should have, or even could haves and won't haves.
Again, with their current knowledge of MoSCoW the participants have to select the feature they want to implement, maximizing the revenue. When they have prioritized their features, they flip the cards to reveal the refined user stories. And then the same exercise as round 2 starts: prioritize the stories to maximize revenue and flip the cards to reveal the actual workload. Calculate the revenue and see how much of the selected features has been implemented.