Agile Requirements Game (aka Draw the Requirements Game)

Update: In the meantime I created an entire Agile Game Collection, including this game (with downloadable images, a visual cheat sheet, as well as video and written instructions).

Teaching teams the importance of face-to-face communication, feedback loops and a close relation with the client can be hard. Games help to feel and understand why this is so important. This article teaches you a little agile game you can play with your teams and coachees.

Some of you may already know this hilarious video of a dad being taught how to create a peanut butter sandwich by his kids … with written requirements ?.

While this video alone can be a nice asset for your next training or coaching, nothing beats experiencing this yourself! Of course you could go ahead and play the “sandwich-dumb” dad for your group, things are even more interesting, if nobody has to act stupid on purpose.

The little drawing game I’ll be describing next helps to let people feel the flaws of written requirements despite honestly trying as hard as they can. And it always gets a few good laughs, too. I slightly adapted the game from the original idea Jason Little posted at tastycupcakes.

Preparation

1. Pick two distinct images for people to draw. I have seen great results with abstract images, but anything should work.
2. You only need one copy of the first image (you can just add it to your slide deck), but you will need a physical copy of the second image, one for each pair of participants (bring 10 copies for a group of 20 people).
3. Bring enough drawing paper and pens for the group.

Pro tip: If you put the first image into your slide deck, add another empty slide right before and after it, so you don’t accidentally reveal the image during your training or coaching session.

Round 1

1. Ask participants to group into pairs. Let them decide, which of the two wants to be the product owner (or equivalent role) and who wants to be the developer (or equivalent role).
2. Then send all developers out of the room for a 10min coffee break. You will see an immediate appreciation of the entire room for the developer role ?.
3. Tell the “product owners” what to do. They will see a picture in a moment, which represents the “product” the customer is asking for. They now need to write down the requirements of that product, so that their developer can draw the picture as close to the customer wishes as possible. The developers will not see the picture, they will just have the written requirements document to work with. Only words are allowed, no drawings. Product Owners will not speak to developers after the written requirements are finished.
4. Give them about 8-10min to write down the requirements.
5. Hide the original picture (just go one slide forward or back in your presentation).
6. Call in the developers.
7. Now give the product owners a 10min coffee break and send them out of the room. They should leave the written requirements for their developer.
8. Tell the developers that their product owners specified a “product” for them to develop. They now must draw the picture that is described in the written document they received from their product owner.
9. Give them about 8-10min to draw the picture.
10. When time is up, call in the product owners. Now you have the whole group back in the room.
11. Let the developers present their awesome pictures to the product owners … and watch the product owners recoil in horror ?.
12. Reveal the original picture (the product the customer really wanted) in your slides. Usually everybody gets a good laugh.

I would defer discussions of the topic to after the second round. Just tell the pairs, that they now switch roles.

Round 2

1. Ask product owner and developer to switch roles. The former developer now becomes the product owner.
2. Watch for the newly appointed “developers” to get up in anticipation of their coffee break … and stop them immediately. This time they will have to stay in the room!
3. Explain that this time the communication rules will be different. Instead of writing requirements down, the product owner will talk to the developer directly explaining the picture. Again: no drawings allowed (that includes pantomime in the air), just words! But this time, developers can ask questions.
4. Hand out a copy of the second image to each product owner. Make sure it is hidden from the developers (upside down or sent via private chat/link in a remote setting). The developers must not see the original image.
5. Again give them 8-10min to produce the final product (=picture). They will usually need far less time than in the first round.
6. When time is up, let product owners reveal the original. The developer’s product will usually be a lot better than in the first round.
7. Debrief

After that second round, the group has felt and intuitively understood the performance boost an agile communication approach has over traditional written requirements. During the debrief you should solidify this feeling and connect it to agile practices.

Debrief

Start an open discussion on what just happened. Focus the discussion on things like:

• Which round delivered better results? Why?
• Face-to-face communication vs. written documents
• Product owner permanently available to developers for questions
• Prototyping. Some pairs start a rapid prototyping approach in round two, where the developer draws a rough sketch and asks “like this?”, then the PO clarifies, the developer draws another sketch and so on. Discuss how this helps in producing a better product.
• How did the POs feel during their break in the first round? They sometimes feel nervous, because they cannot help the developer and just have to wait and hope.
• …

Afterwards the team has a better understanding of why face-to-face communication, prototyping and iteration, feedback and having the PO in the same room is so important. It’s usually a lot easier to convince them to try this new agile approach in their teams now.

Feel free to spread this game to other agile coaches, managers in agile transformations, scrum masters or anyone involved with making their team/company more innovative, productive and happy.

If you want materials to download and in-depth facilitation tips, check out my Agile Games Collection – this game is part of it!