Stay Updated: Posts | Comments   Follow us on Twitter

Posts by :

    User Stories vs Requirements

    November 26th, 2014

    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!)

    VN:F [1.9.16_1159]
    Rate This
    Rating: 5.0/5 (6 votes cast)


    The Newlywed Game

    August 9th, 2014

    Timing: 15 – 30 minutes, depending on the ensuing discussion!

    Overview: This is a game about setting expectations.  That can be setting expectations between a coach and a team, or between a new product owner and new scrum master.  The point is to make getting to know each other and establishing expectations more fun! The ensuing discussion is a great way to establish a coaching agreement between a coach and a new team or to get people aligned on what to expect from fellow team members (IE: what a team expects from their new product owner and vice versa)


    Given a scenario where a new coach is being parachuted into a team that has no experience with Agile, it’s important to set expectations on both sides.  This is a fun way for a coach to communicate to a team what he/she expects from the team
    1. Play the Newlywed Theme song
    2. Enjoy the crazy looks you’ll get from the people in the room
    3. Explain the rules of the Newlywed Game:
        • Each party will need to take 10-15 minutes to write down 3 expectations they have from the other party. IE: the coach will write down 3 things they expect from the team, and vice-versa.
        • One party, in this example, the coach, will be sent to the iso-booth to record his/her answers on 3 big sticky notes.
        • The coach will come back in the room and try to guess the 3 expectations the team wrote down.
        • The team will then try to guess the 3 expectations the coach wrote down.
    4. Have a discussion (decide on a time-box) around where both parties converged and where they diverged.
    5. The big stickies are then posted on the team wall as a reminder about the working agreement that has been formed.
    This game was co-developed with Shawn Button.

    VN:F [1.9.16_1159]
    Rate This
    Rating: 5.0/5 (3 votes cast)


Discuss Login
Recent Comments