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 Criterias.
Instructions:
This is a game to understand Scrum aspects like transparency (Definition of Done) and basic Scrum process of inspection and adaptation. It is based on 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, shown to 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). Team thinks 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 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 facilitator. Use collected results on whiteboard or flipchart to talk about velocity of valuable paper airplanes.
Observations:
Some teams forget the last part of the DoD :).
Some teams split – some team members run the factory, some are testing and showing to PO.
Some teams fail to learn from situations where 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. Good learning point about why Scrum Master is actually is a value.
And yes, in debrief it is worth to mention that PO is just a PO and that this game skips very crucial part – Sprint Review with stakeholders!
Helping Scrum Teams and orgs improve by increasing effectiveness with a wholehearted Agile Coaching.
Good article, thanks for sharing, please visit
our website
I found the original authors!: (https://dzone.com/articles/kanban-paper-airplane-factory Teresa Abney, Adam Nathan, Don Knobbe, Lisa Picker, 2009, documented June 9 2012)
can we change the material with another?
Awesome, Swen-Peter! Thank you for mentioning my name.
Thanks for sharing!
Based on Ivo’s scenario I have created a sligtly adapted version. Feel free to use it under CC BY-SA 4.0: https://bit.ly/paper-airplane-factory
Good to see another variation of place activity. I use the same for discussion on:
– starting the work without understanding the scope (DoD)
– assumptions made by PO and dev team
– re-negotiating when there is a scope creep
Yes, I do have examples of my own. Just did not share those as anyone running the game can create own stories. In short – all 4 stories are very similar, but with some differences so that team has to figure out HOW to build them.
Sounds great! do you have examples of user stories that are effective?