The goal of the Play doh Zoo Game is to explain and practice the reasons behind agile, and the principles that the methodology is built on. It is specifically targeted at designers and aims to highlight the benefits of agile, and illustrate how design activities can occur in an agile environment.

Cathie Hagen, Marie-Claire Dean and Megan Cook invented the game and originally ran this at SxSW 2012. There’s a write-up of that session on Marie-Claire’s blog and also on Adam Kleinberg’s blog (he was a participant).



This game can be run in 60mins (we did so at SxSW), but you can also make it a longer session if you wish.



For the “Customers”

  • Post-It Easel Pad
  • Super Sticky Post-It Notes
  • Coloured Marker Pens

For the Zoo Building Team:

Construction workers

  • Play Doh  (4-6 tubs per team)
  • Coloured Marker Pens
  • Coloured Pencils
  • Large sheets of blue, green, yellow, white paper
  • Pop sticks
  • Tape (masking preferred)
  • String
  • Cellophane
  • Scissors
  • … anything crafty

Business & Design Group

  • Graph paper
  • Coloured Marker Pens
  • Coloured Pencils
  • Super Sticky Post-It Notes

A variety of craft supplies will allow teams to be creative. Therefore, variety in raw materials is encouraged. Also, sharing resources within the team should be encouraged.


  • Timer
  • Whistle (something loud to capture everyone’s attention, especially with a large group)



Split the players into 2 main groups: the customers, and the zoo builders.

The customer group will help the facilitators guide the game play, by acting as customers of the zoos. They will vote with their feet to determine that zoo offers the most fun.

The zoo builders will be split up into teams to compete against each other. Each team will be split into 2 equally sized groups:

  • Planning & Design group (to oversee the overall direction of the zoo);
  • Constructions workers (to build the zoo).

Once the teams have been formed, the game can start. The game is carried out over 3 iterations, during which time the zoo is built. After each iteration, the safety inspector will determine if the zoo is safe to open, and if so the customers “visit” their preferred zoo. A retrospective occurs between each iteration to reinforce the learnings from the game.

After the final iteration is finished, the points are counted and a winner is declared.


Learning points:

The objective of this exercise is to the demonstrate the principles of agile, in particular for experience designers:

  • Working Software – Why it is important to deliver value early
  • Responding to change – How iterative development makes integrating change easier
  • Communication and collaboration – Every team member brings something to the table
  • Customer Feedback – Importance of soliciting and integrating feedback regularly
  • Managing a project – How a success project requires both business and customer needs to be met
  • Retrospectives – How continuous improvement is part of the process

You will learn the above by:

  • Being rewarded for delivering value early
  • Working in a team. We expect successful teams to:
    • Communicate between the groups
    • Co-locate
    • Note: pairing and changing roles is to be encouraged
  • Talking to your Customer. The customer role will provide a demonstration of vague and changing requirements. To be successful the team needs to:
    • Elicit requirements from the customer
    • Elicit acceptance criteria from the customer
  • Sharing your observations with the trainers and learners on:
    • Balancing business and customer requirements
    • Role of a Customer
      • Feedback
      • Acceptance Criteria
    • Adaptive Planning
      • Product Evolution
      • Feature Refinement

Number of Players

This game is designed for a large number of people 50-150.

Each zoo builder teams consists of 3-12 people

The customer team consists of 5 – 50 people. The recommended minimum number of people for this team is twice the number of zoo-builder teams, to allow for greater variance in voting and a richer experience during iterations.

Please note: As the size of players increase, so will the number of facilitators required. It is useful to have 1 safety inspector/facilitator for every 2 zoo-builder groups, a dedicated facilitator for the customer group.


Game play

For each iteration:

  • During an iteration (5 minutes)
    • Customers have specific tasks for each iteration, refer to role description
    • Zoo team builds the zoo
    • Ending an iteration:
      • Safety inspector reviews the built zoos and applies penalties if required.
      • Safety inspector determines whether the zoo is open for business. That is, the zoo must have gate, and at least 1 animal enclosure.
        • If a zoo fails inspection it is closed for business, no points awarded this round.
        • If a zoo passes inspection it is open for business
  • Each zoo showcases their zoo.
  • Customers vote for their favorite zoo. Points are awarded for each.
  • Retrospective (5 minutes):
    • Run collectively
    • Tease out learnings
    • Customers should be allowed to participate in the retrospective


Facilitator Notes: Most teams will be unfamiliar with retrospectives. Provide a quick briefing before the first retrospective to everyone, and assist the teams by helping them focus on process improvement. It may also be useful to provide templates as a framework for the running the retrospectives. The anchors and engines template is an easy, quickly understood template.


Role Descriptions:



Congratulations! You as a customer get to mess with the rest of the teams J

This group will act as customers for the zoo building teams. This team should be located away from the zoo building teams, a break-out room is preferred. Zoo building team members can visit at any time.


Iteration 1

  • Brainstorm what a good zoo should have
  • Rank theses ideas


Iteration 2

  • Discuss trends/events that may effect zoo attendance
  • Vote for a disruptive trend/event. This occurred! The zoo builder teams are told about this event occurring after iteration 2 finishes and before iteration 3 starts.


Iteration 3

  • Mingle and checkout progress early with the zoo building teams.



  • Cannot visit a zoo if the safety inspector has deemed it “unsafe”
  • Can fill in comment cards for a zoo at the end of an iteration during “visit” time
  • Can join a team at any time
  • Can provide feedback to a team at anytime


Facilitator Notes:

The customer group may require hands-on facilitation, depending on the pro-activeness of this group. If needed, help the determining their requirements using fun gamestorming techniques.

Zoo building team

Start with 3 equally balanced teams. The teams can self organize, but people working outside their role are handicapped.

Facilitator Notes:

Resist the urge to prevent the zoo-building team from making mistakes, e.g. overlong planning. Mistakes should be highlighted by the scoring system, and raised within the retrospectives (hopefully by the players themselves).

Construction Workers

You get access to lots of materials. Only current members of the can build the zoo.

Correlation in a software team: developers (front & back end)


  • Cannot start building without a plan
  • Must do what the designers and planners team tells them


Designers and Planners Group

Only have pens/pencils, planning paper, post-its notes. You determine the direction of the build; the construction workers must follow your say-so.

Correlation in a software team: analysts, designers, managers, testers, SMEs.



  • Can assist with building animals/infrastructure, but may only use 1 hand
  • Can request safety briefings and evaluations
  • Customers embedded into team, join this group


Safety Inspector [Optional]

A facilitator will play the safety inspector(s). They provide briefings on the rules that the zoos need to follow. Briefings are carried out with all teams.

The safety inspector also can inspect. Inspections are only carried out for 1 team at a time. If inspecting during an iteration, they act as consultants, allowing the team to correct mistakes without penalty. If inspecting after an iteration is complete, the safety inspector can prevent the zoo from opening, or remove features that are dangerous (e.g. remove a animal which does not have an enclosure), when inspecting at the end of an iteration. Reasons for failing inspection are always explained.


  • Safety rules are clear, concise and straightforward. They do not change during the game.
  • Examples of rules:
    • An animal must have an enclosure.
    • Predator & prey cannot be in the same enclosure (don’t put the lions with the gazelles)

Facilitator notes: The safety inspector should demonstrate the benefit of testing often, and why quality should be embedded into the process.



Activity Points
Basic zoo: gate and gate personnel, and at least 1 animal enclosure


Animals [Optional] 1 for each different animal
Infrastructure/Facilities [Optional] 1 for each facility
Customer votes 1 for each customer visiting