Timing: 30 mins
- 20-30 balloons per team
- Supplies for each team: construction paper, rulers,
Start by showing the teams a balloon that you would like created (or draw one).
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.
- 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.