Requirements game

From Pearl Language
Revision as of 09:32, 28 March 2015 by Martien (talk | contribs) ({{tag|game}})
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Goal

Experience the difference between poor communication with long feedback loops and rich communication with short feedback loops.

Resources

Requirements Game.png

Time

  • 20–30 minutes.

Stuff

  • See PDF document at right:
    • One set of requirement sheets for Round One (pages 2 and 3; ) for each four participants (e.g. three sets for 12 participants).
    • One set of requirement game sheets for Round Two (pages 4 and 5) for each two participants (e.g. six sets for 12 participants).

Round One

  1. Ask everyone to form groups of four people.
  2. Ask each group to split into two analysts and two developers.
  3. Make the analysts and developers face each other (sit on opposite sides of the table).
  4. Hand the developers the blank sheet with only the frame on it.
  5. Goal: Explain that this is their canvas and that they need to implement as many requirements they receive from the analysts as possible.
  6. Make sure no developer can see the requirements sheet and hand the analysts the sheet with the different objects (circles, lines, rectangles, triangles). Any developer seeing the requirements sheet may spoil the game’s learning goals.
  7. Explain that the only allowed form of communication is through written text on Post-it notes going back and forth. No talk, no gestures, no drawing, just text on notes.
  8. Ask if the goal and game rules are clear to all.
  9. Allow eight minutes for Round One. Warn two and one minute before time runs out.
  10. Have all teams stick the results to the wall behind them.
  11. Take five minutes or so to retrospect on what happened.
    • How did it feel?
    • What thoughts crossed their minds?
    • What behavioral patterns emerged?
    • Any insights?

Round Two

  1. Pair up a single developer with a single analyst (simply split each group of four as such).
  2. Have the developers sit at the table and each analysts stand behind their developer, so they can see what developers are doing by looking over their shoulder.
  3. Explain that they will now be able to use state-of-the-art tooling, ‘test-driven development’, and ‘continuous integration’ for value-driven product development.
  4. Goal: create as much value as possible by implementing requirements. Value points are listed in the objects.
  5. Show the blank grid sheet to everyone. The grid with the clearly labeled squares (A1–G5) aid greatly in specifying and implementing the requirements.
  6. Make sure no developer can see the requirements sheet and hand the analysts the sheet with the different objects (circles, lines, rectangles, triangles), that now also have a value associated with each object.
  7. Tell that requirements must be implemented exactly to gain the associated value points, including any shading, 3D, etc.
  8. Allow only four minutes for Round Two.
  9. Have all teams sum the total value generated and stick the results to the wall behind them.
  10. Take five minutes or so to retrospect on what happened.
    • How did it feel?
    • What thoughts crossed their minds?
    • What behavioral patterns emerged?
    • Any insights?

Emphasize the value of (very) short feedback loops and verbal, rich communication over written, poor communication (using Word documents via e-mail, SharePoint); even when given only half the time!

Source: picked up in 2011 during a Certified Product Owner Training with Petra Skapa by Martien van Steenbergen.