When a company is in an agile transformation it’s relevant not to neglect people’s customs. I found it very useful to use games to mingle people’s customs and agile practices in order to gain the best result. But how do you get people to play such games for the better?
An often heard reaction to play games at work is: “We don’t play games, because it’s childish and we have to deal with serious complex material.” The fact is that gaming can help you solving complex problems in your daily job. You might call it childish, but as a child we’ve learned a lot from playing games. So, why did we stop playing? The following quote gives an answer I agree with: “We don’t stop playing because we grow old. We grow old because we stop playing.” Besides it’s true that playing a game is fun, but since when did fun rule out seriousness? That’s where the term ‘serious game’ comes in.
A serious game abstracts a problem from reality. Then a temporary playful world with set rules is created where (part of) the problem is solved by playing the game. The results of the game can be used in reality again to solve the actual problem. That already sounds quite serious doesn’t it? Science states gaming can even be used for training. And it has been proven video games have a positive impact on our brain. So there must be something useful about playing a game, right?
Games that benefit testing
I’ve played a lot of these games last year. Several games were played to demonstrate the essence of agile principles, to help you estimate an amount of work or to solve day-to-day problems, like having to much discussions or encourage communication. Almost all games were inspiring, fun and useful. I definitely had to do something with games. A presentation on games made by my collegue Dajo Breddels was an eye opener for me. From that moment on I decide to use more games at work.
What games can benefit testing? That was the main question I started my quest with. My challenge at the time was to create a regression testset for a new internet portal. Of course we could test everything in a regression set, but as you know testing everything is expensive, time consuming and, since it’s a regression test, often quite boring if done manually. This led me with the question: How can we create a regression testset that:
- has a coverage that all stakeholders would agree with
- cost minimum effort in creating and executing.
I figured a product risk analyses (PRA) was suited for this job. (If you don’t know what a PRA is, check this video.) I was on a tight schedule and I wanted my main stakeholder, functional maintenance (FM), to be more involved with the project teams and the Scrum process. Since Scrum was all new to FM and the project teams were so busy with this agile way of working I thought more involvement would gain understanding and cooperation. Oh and I can’t deny I wanted to have some fun too….and that’s how PRA poker© was born!
PRA poker©
I borrowed the planning poker game that often is played in agile teams and added some testing sauce to it. Functional maintenance and some team members from several teams got together to play this new and exciting game! I arranged some sets of Scrum poker cards and we gathered all the user stories. We were ready to start estimating. No difference there with planning poker. In fact all rules that are effective in planning poker remained in this game. The only thing that I changed was its purpose. Instead of estimating the amount of work, we now had to estimate the risks of the user stories. To do this we used the two determining risk factors that are used in a PRA:
- Chance of failure, which consists of the frequency of use and the complexity to realize this user story.
- Impact of failure, which consists of internal impact (i.e. data loss, amount of work to fix the failure) and external impact (i.e. loss of clients, money and bad publicity) in case a failure occurred following a user story.
For every user story the game was played once. At first the user story was explained in some more detail by the facilitator, which was me. Then risk points were given by everyone, except the facilitator. Risk point were given by playing a poker card. Everyone was given a deck of cards with the Fibonacci sequence till 13. We played 2 rounds of poker for each user story. The first round points were given to the change of failure of a user story. In the second round points were given to determine the impact of failure of a user story.
The fun of the game is that every participant has to lay down the poker card face down. When everyone played a card the cards are opened and you see what everyone estimated. Sometimes the risk points that are given are very similar, then it’s easy to determine the risk points. However if someone gave 1 point and someone else gave 13 points some discussion is needed to come to an amount of risk points everyone agrees on.
The nice thing about the game is that discussion becomes a lot more fun and interactive. By discussing the risks and user stories all participants learn and share knowledge about the new added value that will be delivered to the customer. Not only does this result in a deliberate risk analyses. It also results in understanding each others work and point of views.
After 3 poker sessions of an hour, all 71 user stories were given risk points everyone agreed on. The result was plotted and categorized in a risk quadrant. We had just determined the coverage a user story would be tested in the regression test set.
Risk quadrant
32 of the 71 user stories were categorized in the lowest risk category and will therefore not explicitly be tested. Despite that fact FM had a good understanding and feeling about what will be tested in the regression test set. Prior to this PRA game FM just said everything had to be tested in the regression test. Hurrah for playing PRA poker!
Not everything went perfect (it was quite time consuming) and the game will have to be improved, but the experiment was a success. FM was so enthusiastic that they keep asking when they can play again. Luckily for them new parts of the portal will be released very soon so new PRA poker will be played. In my next blog post I’ll continue the story about how we improved the game and how we used the outcome of the PRA poker sessions to automate the regression tests.
I was really surprised by the effectiveness and the fun people had playing such games like this. I will definitely play (and create) more games. Want to try PRA poker yourself? Get yourselves a deck of Scrum poker cards and start playing for the greater good!
Update: At the same time I ‘invented’ PRA poker other people had the same idea. For instance look here for a nice article on risk poker.