Timing: 25-30 min. (For 2 teams with 1 facilitator)
Materials
Prepared in advance: 4 User Stories (in 2 copies each) describing different planes to be built.
Room with 1 table for each team, many A4 format paper sheets, flipchart or whiteboard, anything needed for teams to be able to build airplanes according to Acceptance Criteria.
Instructions
This is a game to understand Scrum aspects like transparency (Definition of Done) and the basic Scrum process of inspection and adaptation. It is based on a well-known Paper Airplanes game (one variant here) and is modified to go away from the factory of producing as many airplanes as possible towards producing airplanes that are valuable.
Definition of Done
Paper Airplane is built, tested, and shown to the PO (facilitator) that it flies!
The game is organized in 4 Sprints. Each Sprint starts with Planning, then proceeds into Sprint work, then into Sprint Retrospective.
The only rule
Is that each team member can do one bend at a time and then has to pass the airplane to someone else in the team.
Sprint Planning
PO (facilitator) starts the timer (1 min) and gives each team the same 1 NEW User Story describing the plain to be built with Acceptance Criteria (AC). The team thinks about HOW to build it.
Sprint Work
When 1 minute is over PO (facilitator) asks to start the work and reminds that teams have 4 minutes! Teams start building the planes according to AC and DoD. PO (facilitator) marks the count of acceptable to him airplanes on the whiteboard or flipchart per each team.
Sprint Retrospective
When 4 minutes are over PO (facilitator) asks to stop working and reminds that teams now have 1 minute to retrospect their process. After 1 minute is over, Sprint Planning starts again by PO (facilitator) giving each team the same 1 next User Story.
After 4 Sprints, teams debrief the game with a facilitator. Use collected results on a whiteboard or flipchart to talk about the velocity of valuable paper airplanes.
Observations
Some teams forget the last part of the DoD :).
Some teams split – some team members run the factory, and some are testing and showing to the PO.
Some teams fail to learn from situations where the PO rejects some of the planes.
Running this game w/o a Scrum Master is hard as at some point the busy PO misses to notice the timeboxes. A good learning point about why Scrum Master is actually valuable.
And yes, in the debrief it is worth mentioning that PO is just a PO and that this game skips a very crucial part – Sprint Review with stakeholders!
