Some time ago, I included a couple of serious games in a requirements exercise. The participants included people from both the IT organization, who were getting the requirements, and the business people, who were giving them the requirements. The result shows how serious games can change the conversation between the producers and consumers of technology.
[Unfortunately, I can’t name the company, since I don’t have their OK to do so. If and when they do give their permission, I’ll definitely include them as a success story.]
There were four groups, each with its wish list of high priority requirements. Unsurprisingly, the net result was a single list with far too many high priority items. When everything is high priority, nothing really is, so we needed a way to attack this challenge from a different direction.The participants were having a tough time being ruthless about prioritization. We ran two games, Buy A Feature and Prune The Product Tree. The list of requirements used in both exercises was a small subset of the massive list of all requirements, so the objective wasn’t prioritizing everything. Instead, the goal of these exercises was to show that the business users could be a lot more disciplined about prioritizing their requirements, and developing some new ground rules for sharpening their prioritization.
The Buy A Feature session ended with an interesting result. The groups included representatives from all groups, including IT, so there was no chance that one group would disproportionately favor one part of the business over another. When they finished, their lists were very similar, with most of the lists containing the same projects. Clearly, the participants were starting from a similar understanding of the business value of each requirement. Now, they just needed to be a bit more ruthless in applying these measures of value.
By the time we played Prune The Product Tree, the participants were willing to be a lot more precise about business value, and a lot more clear in their minds about how an individual requirement contributed to one of several corporate objectives. Some of the requirements for which people had argued passionately as a top priority drifted to the edges of the tree, indicating a lot lower priority than they originally had thought. A few requirements looked conspicuously alone on the tree, unrelated to other priorities, making it harder to see how they contributed to business outcomes. (In this game, you cluster related requirements on the tree.)
The visual aspect of Prune The Product Tree made it much easier to lower the priority of some requirements, much to the relief of the IT staff who will be implementing them. You have to place each requirement in a visual context; here, if it belongs with a particular corporate initiative, and there, f you want to show how it’s connected to another requirement. I’d venture that getting to this result in the usual way – verbal arm-wrestling – would have taken much longer, and had been a lot more contentious. In other words, serious games gave the participants a way to have a real conversation about the value of software requirements, instead of the typical confrontations.
