Organization and prioritization are two distinct activities that can be used to improve the quality of a product backlog. A simple linear list is difficult to prioritize. As well, many stakeholders are forgotten in the rush to deliver customer value. See example list of stakeholders. The purpose of this game is to expand the view of multiple stakeholders as well as illuminate the value of organizing the work without prioritizing.

Learning Points

● The value of organizing before prioritizing

Timing

45 minutes. (Variant: drop a round to shorten)

Ingredients

The game consists of the following items for each participating team:

1. Persona Cards: (5”x8” cards) There are four persona cards or sheets. Each persona should be copied to a separate card.
2. Story Cards: (3”x5” cards) In this game, the stories consist of a verb and a noun (e.g Fertilize Crops). There are 18 cards, but more cards can be added. One verb noun grouping should be copied to each card.
3. Category Cards: (3”x5” blank cards – use different colour than story cards) – The category cards are initially blank. A set of blank cards are needed for each round and team. Typically there are around 5 Categories per round.
4. Black Marker: Any pen or felt tip mark should work. This is used for writing on the category cards. One timer is needed in order to time each round and the debrief sessions.

Recipe

1. Introduction (5 min)
   • Draw simple Product Backlog in Scrum
   • Ask participants what it is
   • Comment that there is a lot of complexity that may not be best represented by asingle sorted list.
2. Form the group into teams – each at a table. (2 min) 4 seems a good number for a team. More than this and it is hard to jointly sort the cards. 5 may be OK.
3. Introduce the domain. Once upon a time, there was a farm and different people had different ideas how the farm should be run. (MORE)
4. Iterate! There are 4 rounds – each with a different persona (see table below)
   • Shuffle story cards between rounds
   • Introduce Persona (1 min + 1 min for questions)
   • Ask participant organize the backlog based on the persona.
   • Debrief the round. Do this in a circle. See debrief questions below.
5. Debrief the whole game.

Round 1

• Persona: Producer/Farmer
• Round Duration: 5′
• Debrief*: 4′

Round 2

• Persona: Customer/Buyer
• Round Duration: 4′
• Debrief*: 3′

Round 3

• Persona: Farm Bureau/Inspectors
• Round Duration: 4′
• Debrief*: 3′

Round 4

• Persona: Land Owner
• Round Duration: 3′
• Debrief*: 10′ – whole game

* Larger groups may require more debrief time.

Debrief Questions

First Round

• Each team: talk a little about how you organized the backlog.
• What is the same/different?
• What else did you notice?
• If no one mentions, may notice that we are used so used to prioritizing we often go there automatically. Did any of the teams create a structure that helps them understand their world?

Second/Third

• Same questions as first plus
• What was different from earlier round(s)?

Final

• Over all 4 rounds, what have you noticed about backlog organization?
• How does this relate to product backlogs that you work with?
• How well do real world product backlogs represent different stakeholders?

Story Cards

There are 18 story cards. Each story card consists of a verb and noun pair.

(Note: Michael S removed story numbers since it may confuse people)

Stories:

• Fertilize Crops
• Spray Insecticide
• Harvest Crop
• Buy Seed
• Rotate Crops
• Weed Fields
• Survey Market
• Kill Groundhogs
• Lay Fallow
• Define Market Needs
• Till The Ground
• Assure Organic (inspect for selected crops)
• Plant Seed
• Sell Early Summer Crops
• Sell Late Summer Crops
• Water Plants
• Recover from Natural Disaster
• Forecast Profit

Personas

Producer / Farmer

As a farmer, I’m focused on legally maximizing my profits by controlling costs, buying the right seeds, planning crop rotations, reducing pests, and timing the release of my products to markets. I follow closely the agreements set forth in the lease with the Land Owner.

Consumer / Buyer

As a customer of the local farm, I want healthy and reasonably priced food that has been grown with sustainable and environmentally friendly practices.

Land Owner

The farm land has been in my family for over 200 years. My family’s income depends on the revenue generated from the farm lease. Hence, we are interested in ensuring the long-term sustainability of the land. As a family, we have been engaged in wildlife preservation and conservation of natural resources. It is imperative our property used in accordance with all relevant laws and regulations.

Farm Bureau / Inspectors / Regulatory Agencies

As a regulatory body, we are tasked with ensuring that produce is safe and fit for human consumption. We test and verify that the land is used in accordance with local, state, and federal regulation to protect from erosion, run off, soil depletion and other activities that may harm the land. We enforce all animal protection laws and regulations.

FAQ

There are no story points (cost). How does this make any sense?

The whole point of the game is to ignore prioritization. Story cost is only relevant for making prioritization decisions. In this game we want people to think about stakeholders and how to organize the work in terms of who cares about what.

Credits

This game was developed at Deep Agile 2010 in Boston by:

• Michael Sahota
• Mary Gorman
• Warren Elliott
• Greg Ott
• Dan Zaino
• Judy Rivais

Ingredients:

• 100+ Toothpicks (or something similar)
• At least one Die

Directions:

Participants line up in a row with a collection of toothpicks (or something similar) placed with the first participant. The first participant rolls a die to determine how many toothpicks to pass to the next participant. Each participant then takes turns rolling the die and passing the corresponding amount of toothpicks to the next player. The final player creates a stack of toothpicks based on his/her roll and then passes the die back to the first participant to continue with the next round. Play until it is obvious where the stacks are forming.

Learning Points:

• Even though all participants have the same odds, inventory still piles up. Tie this in to Value Streams and software.
• In software, requirements are your inventory. It is wasteful to process them all up front.

CREDIT: The Goal, Dr. Eliyahu M. Goldratt, 1984

Posted by Mike

Ingredients:

• 20-30 balloons per team
• Supplies for each team: construction paper, rulers, scissors, markers

Directions:

Start by showing the teams a balloon that you would like created. The balloon has a face made up of two round eyes, a triangular nose, and a semi circle mouth. Without any further instructions, tell the teams that they have 2 minutes to create as many of the balloons as possible, then have them bring the balloons up to be ‘accepted’. Eliminate any balloons that do not meet your criteria of ~10 inches wide, ~2 inch eyes, ~1 inch gap between eyes, ~1.5 inch high nose, and ~4.5 inch wide mouth. Very few teams will have balloons that meet the criteria. As you reject their work (waste), ask the teams if they’ve ever had a similar experience in software development. Before the second round, give the teams 2 minutes to discuss how they can improve for the next iteration. They should start asking more questions about the acceptance criteria, which you will happily offer. When round 2 starts, the teams will now apply the acceptance criteria to their work and some will even start building ‘test harnesses’ (e.g. paper templates for face, quick ways to measure balloon width, etc.) . The results should be better in round 2. Discuss how they changed the way they worked and what improvements they would make the next time. If needed, play one more round. This time, every team should be using a test harness and should therefore be producing balloons with much more efficiency and quality.

Learning Points:

• Defining acceptance criteria is not the same as writing tests, only to be applied after something is produced. They can be used as requirements, as tests, and as a target for developers.
• Automating acceptance tests (or executable requirements) can be very useful, as demonstrated by the test harnesses produced during the game.
• The investment in creating and automating acceptance tests is worthwhile and has a high return.

Posted by Mike

Ingredients:

• 2 equal sets of wooden train track with some complexities (bridges, tunnels, etc)
• Create a set of requirements and put a score on each (Different degrees of complexity and value are important)
• Test the event yourself to get a sense of time

Directions:

• Split into at least two groups
• Split the groups into the “big release” and “iterative” groups
• Tell them that their customer is a parent who want to “buy” a product to keep their child entertained
• Explain that you are willing to pay higher amounts for more requirements being met, for example:
  • A train track with no dead ends is worth $25
  • Bridges that go over track (instead of nothing) are worth $10 each
  • Track that isn’t tense and has some wiggle in it is worth $5 (keeps it from being forced and broken)
  • If every piece can be reached without lifting the train, that is $25
  • If every piece can be reached and crossed in both directions without lifting the train, that is $25
• Tell the “big release” group that they will go until they decide to ship their product
• Tell the iterative group that they should strive to ship a product at the end of every minute (you tell them when they have 10 sec to go)
• Go!
• Every minute, take a snapshot and determine how much money the iterative group would make if they shipped their product at that moment
• When the “big release” group meets all the requirements or calls it quits, stop the game.
  • In theory the iterative group will have banked money over each iteration and made multiple times the amount of money the big bang group would have made. Talk about how long it will take the iterative group before they have to match the other group’s requirements. Talk about how this would play out in real life if each minute was equal to a week of work.

Learning Points:

• Understand how sprints affect delivery
• Delivering business value sooner is more profitable
  • Have a shippable product each sprint to do so
• You can retain customers by giving them something simpler and working to the “real” goal over time
  • would the customer have waited for the “big bang” group to deliver the full product or appeased the crying child with the iterative groups earlier solution (remember… minutes equaled weeks of dev. time)

CREDIT: Kevin Schlabach

Posted by Mike

Ingredients:

• Origami instructions for half the participants
• Blank standard sized printer paper for half the participants

Directions:

Pair up participants and provide an instruction sheet (face down) to one person in each pair (the “instructor”), and provide a blank sheet of paper to the other member of the pair (the “folder”). Split the pairs into three groups:

• Group 1 sits side-by-side,
• Group 2 sits face-to-face, and
• Group 3 sits back-to-back.

On “Go!” the person with the instruction sheet flips it over and instructs the other member of the pair how to fold the origami.

• In Group 1, one person folds, but both can consult the instruction sheet as much as needed.
• In Group 2, the folder must not see the instruction sheet, but the instructor can watch the folder and provide feedback on progress.
• In Group 3, the instructor and the folder cannot see each other, but they can talk (over their shoulders) as much as possible.

As each group successfully completes the origami item, have them stand up. The facilitator may cut it off after a period of time, because Group 3 may not successfully finish.

Learning Points:

• Collaboration leads to faster results and better quality.
• Communication barriers on geographically dispersed teams can be disastrous, even if there is unlimited verbal communication.
• Visual maps are a useful communication tool.

CREDIT: Ken Howard, Improving Enterprises

Posted by Mike

Ingredients

• People and space
• Notepads and pens for participant

Directions

1. The moderator whispers a short phrase, such as “The company is facing budgetary problems, and some of us will be let go,” in the ear of a participant. The moderator writes down what he whispered.
2. The participant then whispers the sentence that he heard in the ear of another participant and writes down what he whispered.
3. Repeat step 2 until everyone has participated.
4. The moderator then asks each participant to read aloud the sentence that the participant wrote down.

Learning Points

• The morale will deteriorate quickly, often in comical ways. Invite the participants to discuss why communication is intrinsically noisy. Discuss practices that promote good communication.

Submitted by Michael dela Maza <MdelaMaza @ drc.com>

Posted by Mike

30 mins

Ingredients

• Supplies for each team: play dough, pipe cleaners (chenille stems)

Directions

Each team selects one Business Analyst (or Product Owner) to come to the front of the class to look at a picture of an item that the customer wants built. The BA’s are instructed to only use imperatives and similes (no ‘rhymes with’) and to not use certain words when describing the item to the rest of their team.

• In round 1, the item is something simple (such as a chair), but the BA must communicate only in writing. This should only take a few minutes for the team to create using the given supplies.

• In round 2, the item is something simple (a teapot), but the BA can speak with their team. This should show how much easier it is to communicate by speaking.

• In round 3, the BA is shown an item that isn’t as easy to communicate (a motor-cycle RV or a make-up kit built in to a computer mouse for instance). Since items like these are not common, it should be much harder to build.

Note: A quicker alternative to this game is to have teams draw the items instead of using the supplies.

Learning Points

• In software, we are rarely creating something that already exists. So we are forced to communicate in imperatives and metaphors and, quite often, much is lost in translation.

Posted by Mike