This game was originally created by Phil Abernathy from Purple Candor, this game has been subsequently modified by Renee Troughton and Craig Smith to include requirements that vary each snapper. This game has been run over a dozen times.
The Project Snapper game is a quick 45 minute game to realise the value of establishing firm acceptance criteria and the importance of having everyone who is part of the team part of the Inception activity, however this can be used to introduce the simple concepts of Scrum such as Sprints, Sprint Planning, Sprint Reviews and Retrospectives. Using an instruction guide an origami snapper, teams are encourage to build the snapper and modify it so that it meets the requirements output from Inception.
The aim of the game is to build twenty snappers in two Sprints. This game is normally done in a forty-five minute time block: 5 minutes upfront for instructions, 30 minutes for two Sprints and 10 minutes for debrief.
Materials and setup
Each team of 5-6 people requires the following:
- 2 printed Snapper instructions
- 1 set of Inception requirements handouts
- Set of coloured pencils or crayons (preferably crayons)
- A stack of 25 plain white A4 paper
The Inception requirements handouts can be post-it notes, index cards or simply a few A4 pages with the requirements written out on them as if they are post-it notes. The requirements for the snappers don’t matter too much, what matters is that as a Product Owner you have a clear idea of how you will assess the validity of the snappers to meeting your needs. Examples of some snapper requirements (with undisclosed acceptance criteria in brackets) are as follows:
- Orange Triangles (must be equilateral with an edge of at least 1.5cm)
- Rainbow (must be in the order red, yellow, orange, green, blue, purple)
- Dracula (like count Dracula from the muppets – purple with a black widows peak, two fangs, one of the fangs is dripping blood)
- Scarlet Johansson (must have big red pouty lips and the Black Widow hairstyle)
- Robert Downey Jnr (Iron man goatee and bling sunglasses)
- Wet snapper (physically wet but still somewhat recognisable as a snapper)
- Pink crane (a trick requirement, must be a crane origami snapper of a different pattern than the instructions)
- Pink polka dots (following the standard on wikipedia)
Twenty requirements all up are needed.
Kicking the game off
The instructor needs to walk the participants through the following rules:
- Each Sprint will be 15 minutes – 2 minutes for Sprint Planning, 8 minutes for build and test, 3 minutes for review and 2 minutes for a retrospective
- Determine who in the team will be the Scrum Master, who will be building snappers, who will be drawing snappers and who will be testing the snappers.
- The first Sprints two minutes can be used to prototype a Snapper if needed
Additionally the following should be highlighted:
- The objective is to build 20 snappers by the end of two sprints. These snappers were as per discussed at Inception to which everyone in the room was a part of.
- The instructor (you) are also the Product Owner
- You should understand from a Product Owner perspective which snappers you want built first.
- If asked what snappers are priority then reveal the first one of two but do so carefully so that other teams do not hear.
- It is okay for team members to go outside of their initial roles of Scrum Master, building, drawer and tester.
- Teams will learn swiftly at the end of the first Sprint that the complexity is not in building the snapper but more in getting the requirements right. The pressure to support multiple teams as a Product Owner in the second Sprint will be significant, especially at Sprint Planning.
- Highlight throughout the Sprint when you respond to the questions that they knew the answers already because they were involved as part of Inception.
At the end of game the instructor should ensure that the following are brought to light (if not already discovered through retrospection):
- Was anyone really at Inception? The reality was no, but we think that because we have requirements in front of us that we have all that we need to know and dismiss the value of a shared understanding
- The value in reducing rework through having a good understanding of acceptance criteria upfront
- Why did teams not combine to deliver the 20 snappers?
- Was the goal of 20 snappers realistic?
- That the difficulty, whilst first was understanding how to build snappers, it then deepened to how you really build to the requirements. This reflects building to risk of architecture/infrastructure first and then focusing on value
- Did anyone build a visual management board to track the work? Why not? How did you know which ones were accepted versus failed?
- Did anyone do a Daily Scrum? Why not?
- Was prioritisation of requirements clear?
- What roles were relevant?
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.