Tag Archives: user stories; fun exercises

A Simple Collaboration Exercise to Show Why Written Requirements Don’t Work

A couple of weeks I was playing the XP Game with a client and one of the stories in the game is to blow up a bunch of balloons to a certain size and tie a knot in it.  A funny thing happened.  One of the more dominant personalities playing the game interpreted ‘knot’ literally and ‘added a feature’ to the balloon by taking the string provided in the game materials and tying a knot around the opening of the balloon.

They finished the story and showed it to the product owner and he couldn’t figure out why there were a bunch of strings dangling from all the balloons.  A team member showed him the card that clearly said “tie a knot…”   Every other time I’ve played this game people simply tie up the open end of the balloon. Continue reading

Simple Exercise to Demonstrate Value of Collaboration

This is a quick and simple exercise I ended up doing ‘off the cuff’ but based on feedback from the class, had huge value that talked about why the conversation is the most important piece of the user story.

I focus heavily on making the point that the written word is less important and while INVEST shows us there are good ways and bad ways to write stories, the disconnect is always a result of lack of communication.

This exercise takes Mike Cohn’s “entree comes with soup or salad and bread” statement from his User Stories book and allows small groups to write down what they are giving me when I order that in a restaurant.

Tools required:

- whiteboard or flip chart to record the responses
- a few sticky notes or paper for the small teams to write on
- pens
- play-food could be optional to make it more fun!

Set the Stage:

Have the group split into small groups of 3, depending on class size.  I had 3 groups of 4 in this particular class.  As product owner, I want to order the entree with soup or salad and bread but I have to run to another meeting, I expect to get what I ordered by the time I get back.  You can leave the room, but I stayed in the room to hear the type of conversation that is happening.

Timebox: 5 minutes (up to you I suppose, I figured that was reasonable)

Expected result:

- ideally you will get at least 2 different orders.  In this case, each group gave me 3 different orders which was perfect to demonstrate the value behind the exercise

Observations:

- immediately I heard conversations like “what did he mean?  does he want soup or (salad and bread) or (soup or salad) and bread?”
- didn’t hear conversations like “we can’t do this until we can ask him what he wants to clarify” – all 3 groups just decided to guess and hope for the best

Learnings:

- the conversation is the most important part of the user stories’ 3 C’s.
- focus on the conversation, not the text in the story
-  the conversation to clear this scenario up is 1 minute or less as opposed to the effort required to revamp the documentation, then update the story in your tool
- business people and developers MUST communicate daily

I just thought about this as the class was starting so there was zero prep or thinking, just figured it was better than me blabbing on and on about why people should talk to each other!  I plan to try this exercise again, the feedback from the group was unanimous.  They all ‘got it’ that the point of the user story was the conversation.  I start each class with a focus question and this exercise quickly answered about half of the responses.  Most were concerned about the story missing details, how can I write better stories for the team etc.

Would love to hear your thoughts!