Nov 2017: Sorry for the broken links…when Dropbox nuked their public folder support, this link went with it! It’s fixed!

Disclaimer: I learned this exercise from Sarah Klarich, I don’t know where she learned it from (Teresa Carlisle according to the document author?) but it’s extremely effective at communicating why User Stories work better than requirements! Hint, it’s NOT about the User Story!

Materials Needed

  1. Blank paper (cut standard printer paper, 8.5 x 11, into quarters)
  2. Sharpies or pens, optionally have coloured sharpies available
  3. Download and print the ‘product’ pages


Fantastic to play with a whole team during a liftoff. It is not a good idea to run this with a group of BA’s or one functional group. The whole point is about cross-discipline collaboration.

How to Play

  1. Pair people up. One person will play the role of Developer, the other will play the role of Product Owner (or product manager, business person…etc)
  2. Ideally have less-technical people play the Developer and have the more-technical people play the Product Owner
  3. Once the group has chosen roles, ask the Developers to leave the room
  4. Round 1:
    1. Give the Product Owners the first diagram that you downloaded and printed.
    2. Give them 6 minutes to write a requirements document that will allow their Developer to re-produce the drawing.
      1. They cannot draw symbols in their requirements document
      2. They cannot show the Developer the diagram
    3. When the timebox expires, ask them to hide the diagram and invite the Developers back into the room.
    4. Have the Product Owner give the requirements to the Developer and tell them they have another meeting to run to but that the requirements document has all the details they need!
      1. The Product Owner cannot help in any way other than to clarify messy writing that the Developer isn’t able to read!
    5. Give the Developer 6 minutes to draw the diagram
    6. Do a show and tell at the end and ask the Product Owners if they would accept the product. Record the yes/no responses and post the product images on the wall
  5. Round 2:
    1. Give the Product Owners the second diagram from the file you downloaded and printed. Make sure the Developers don’t see it!
    2. Give the Developer 6 minutes to produce the new product but allow the Product Owner and Developer to collaborate as much as possible:
      1. The Product Owner cannot use hand signals
      2. The Product Owner cannot draw the diagram
    3. Do a show and tell and ask the Product Owners if they would accept the product. Record the yes/no responses and post the product images on the wall.
  6. Ask the group to describe the differences between Round 1 and Round 2.

Typical Observations

  1. Round 2 took half the time and the product is WAY better (this is a dangerous learning though because Agile doesn’t mean faster, better and cheaper!)
  2. Some Developers build a prototype (IE: they draw a circle on a separate piece of paper and ask “is this right?”
  3. Some Developers throw out the paper and start over
  4. The rapid feedback during round 2 is the difference, the ability to clarify sooner is the main reason for delivering a better product
  5. Some will argue that the exercise is stupid because requirements documents include diagrams when needed. At this point, throw those people out of the class and tell them they must never ever ever practice Agile! Oh relax, I’m just kidding. Mostly.
  6. Developers learn that writing requirements is really hard!
  7. During round 1 you may hear “I assumed when you wrote that statement you meant…” (assumptions are dangerous!)

Sample Results


  1. Write the requirements yourself and give the same requirements to everyone and explore how completely different the drawings end up being.
  2. Have one person in the session write the requirements (same as above but saves you from doing it!)

11 thoughts on “User Stories vs Requirements

  1. Excellent game, love it!
    With some adaptation, it also works in an online context; I’ve successfully used it when teaching via Zoom (using breakout rooms). Thanks a lot!

  2. Just wonder if the link to the products and diagrams pages have been migrated to somewhere as it doesn’t seems to work. Thanks.

  3. This is a gem… it worked great at about 10:00am of a 1 day workshop and a great way to take a controlled break.

    The results on round 1 were as described… The 2nd round was terrific, a real eye-opener for everyone and a big hit.

  4. I organized this short game during my Agile workshop three times this year (2016). I got very positive feedback. The game is easy to organize. Great fun for students and great conclusions. Works really well as an introduction to User Stories.

  5. Yes it’s a popular game. Sometimes it can feel like the result is obvious or self evident so why play it. That can put a dampener on the result. Be careful on how it’s presented with out too much leading. Most groups get it though even though it seems obvious. A common refrain nonetheless, but not evident until it’s played or maybe not spoken about openly – I know this dichotomy exists.

Comments are closed.