User Story Taboo

For my agile workshops I created a little game called "User Story Taboo" which I'm using to teach attendees how to write user stories. Here's the game description.

Participants

4 - 16

Duration

• about 60 - 90 minutes (normal version)
• about 90 - 120 minutes (extended version)

Goal and description

The goal of the game is to make participants understand how they can write good user stories.

User Story Taboo is based on the board game "Tabu" where teams have to describe words and terms without using certain forbidden words.

The participants will write user stories but they will be forbidden to use certain words. This is to show participants that no one needs user stories like "As a server I want to...". They shall learn the pros when not only defining the functionality but also who it is for and how he/she will benefit from it.

We are doing this by writing stories for an extended version of battleship. The rules for battleship are well known, thus we can concentrate more on writing the stories instead of discussing the rules of battleship.

Forbidden words

User

better

faster

end-user

operator

client

customer

server

to look at

work

company

stakeholder

program

system

product owner

game producer

easy

Preparation

• Print requirements
• Write forbidden words on flipchart or print them

Setup

• Divide participants into groups of max. 4 people
• Give each group a part of the requirements. Ideally each group has the same amount of requirements

Game

Round 1: Write user stories

Explain to the participants that good user stories describe who wants to have something, what he/she wants and why he/she wants it. In my experience providing the common template "As <role> I want to have <functionality> so that I have <value>" helps the participants in writing their first user stories. Show and explain the forbidden words.

Now let the participants write their user stories. Sometimes this takes 2-3 iterations until the stories meet all the requirements (who, what, why) and omit all the forbidden words.

Round 2: Acceptance criteria

Explain acceptance criteria.

Let groups select 2 user stories from round 1 and make them write acceptance criteria for them (encourage participants to be creative here :)

Extended Version: Groups don't select the stories but each group writes the acceptance criteria for all their stories from round 1.

Round 3: Identify epics

Explain epics and the lifecycle of a requirement (Requirement -> Epic -> User Story -> Task, etc.). The rules from the ebook "5 Rules for Writing Effective User Stories" are a good basis and orientation.

Let participants take a look at the written stories and make them identify epics and user stories.

Extended version

Round 4: Split stories or epics

Explain how to identify stories that are too large (e.g. words like and, or, but, etc.)

Let groups select 2 user stories or epics and make them split these stories/epics.

Backlog-Management

Show and explain participants possibilities to manage the backlog. Some possibilities:

• Impact Mapping
• Relative Weight Priorisierung
• Agile Strategy Map

You can also find all the materials in German and English on Github.

The Definition of done workshop

Recently one team I take care of as a Scrum Master needed a Definition of Done. Since I couldn't find anything on the internet about a corresponding workshop or a good method to create a definition, I created a workshop based on the "Challenge Cards" method from the book "Gamestorming" (page 158). Here's how you do it:

Time needed:
About 30 - 60 minutes

Preparation:
Prepare green and red colored post its and a blank flip chart (or similar).

How to play:
Divide the team into two groups. One group is the problem group, they get the red post its. The other group is the DoD group, they get the green post its. Now give both groups 10 minutes time.

Ask the problem group to think of common problems the team encounters regarding development, which could be fixed by a definition of done. Examples would be "a lot of bugs", "released version doesn't work" or "duplicate data appears". Important: Point out that it's not about problems the team can't be made responsible for (kernel panic on a server for instance), but that it's about problems that occur due to errors made during development.

Ask the DoD group to come up with possible items for a definition of done. This can be anything they can think of.

After the 10 minutes, ask the problem group to post their first problem on the left side of the flip chart. Now ask the DoD group to post one or more items that can solve this one problem on the right side of the flip chart. Let them draw an arrow going from the DoD item(s) to the problem post it. Notice that there can be more than one DoD items solving a problem and that one DoD item can solve multiple problems. It is ok and desirable to draw arrows from already posted DoD items to a new problem.
Continue until all the problems have been posted.

Now there are 3 possible outcomes:

You still have DoD items left.
Ask the DoD group to post them on the flip chart. After that, ask the whole team if they can think of more items they would like to include on the definition of done.

You still have problems that don't have a possible solution.
Ask the whole team if they can think of anything solving it. After that, ask the whole team if they can think of more items they would like to include on the definition of done.

Every problem has at least one possible solution.
Ask the whole team if they can think of more items they would like to include on the definition of done.

As a last step go over all the DoD items that have been posted on the flipchart during the workshop and ask the team if this item makes sense on a definition of done and if they agree, if this item lands on the definition of done.


Example:
Our result looked like this