Timing: 30-60 mins
Ingredients:
- Index Cards
- Supplies for each team: construction paper, glue, rulers, scissors, markers
- Magazines for clipping images
- Iteration status board (whiteboard, wall, etc.)
Directions:
In teams of four or more, participants must agree on a wish list for what they would like to see in a brochure for their ultimate resort. Using index cards, teams must then write user stories for the brochure (e.g. As a parent, I want a kid friendly atmosphere so that I can feel comfortable bringing children; As an owner, I want to advertise a special offer so that I can attract more vacationers; etc.). The team’s elected Product Owner must then prioritize each story by placing the cards in order of importance.
The teams then prepare for a 12 minute iteration (three 4 minute days) by selecting which stories they think they can accomplish in the first iteration. For each selected story, the team defines acceptance criteria (definition of ‘done’) in order to clarify requirements and to extract tasks (e.g. find picture of beach, write the resort name on brochure, create layout, etc.). Each task is placed on an iteration status board in the ‘Scheduled’ column and the iteration starts.
Each day of the iteration should start with a quick Scrum meeting, where the participants move tasks over to the ‘Completed’ column and volunteer for tasks by moving them over to the ‘Active’ column. Any blocked tasks are moved to the ‘Blocked’ column. After the Scrum meeting, each member should start producing in accordance with the acceptance criteria until the three days and the iteration end. An iteration should end with a demo of their progress and a retrospective, in which each team lists what they did well and what they can improve on for the next iteration. Repeat iterations as necessary.
Learning Points:
- This is a great mini-simulation of Scrum. It provides each participant with a sense of control and visibility in to all the work that is going on.
Posted by Don McGreal
Looks to me like the players start off as customers (or customer proxies) for the user stories workshop, then switch to developers and stay that way. Is that right? Would it be useful to remove the ambiguity by pre-generating the stories, or by having crew act as customer proxies?
If this is a good option, do you have a stack of sample stories for this game?
Hi Gwyn,
I like having the whole team come up with a wish list of the ultimate resort brochure because it adds originality and fun. However, I then like to ask the teams, based on the creative mess they generated, if they have a clear vision for what the brochure will look like. This is a good time to introduce the role of Product Owner, which each team needs to select. The PO is responsible for prioritizing and reining in the backlog and establishing a vision. During implementation, the PO doesn’t do any of the tasks, but need to be available to the team for questions and feedback. The PO then accepts or rejects the work in the sprint demo. Over time, I have put more and more emphasis on the PO role during this exercise and have found that it enhances it quite a bit.
As a side note, I have stopped asking the teams to write their wish list in the form of user stories. I just ask them to write down what ‘features’ they would like. I have also found that having the PO more involved, I do not have to explicitly ask teams to write acceptance criteria. This simplifies the exercise while staying in step with Scrum, which does not prescribe any user story or acceptance testing templates.
This exercise, however, sets up a great introduction for both techniques later on.
As far as sample stories/features, here are a few common ones:
* Show off sandy beaches
* Show people having fun
* List amenities
* List activities
* Adults only. No Kids!
* Show room sample
* Display contact information
* Full bar
* Golf
* Resort layout/map
* Display distance from airport(s)
* Stands out from other brochures (non-functional)
* Can be mailed in standard envelope (non-functional)
* Nude Beaches!
Gwyn, I hope that helps. Please let us know if you have any other questions.
We would love to hear your experiences if you choose to use this one (or any others).
Thanks,
Don
Thanks for your response. We’re planning to run a big session of this next week, so I’ll let you know how it goes. The idea is to run it as almost the last activity of the day, giving the trainees some practical experience in all the things we’ve been talking about.
We ran this yesterday to two groups of 8. Selecting a PO from the team works very well. We had the team generate stories directly, rather than going via brainstorming, in the style of a User Stories Workshop. We also used two 6-minute days instead of three 4s. We found that the scrum masters (facilitators) had to be _very_ on the ball to keep the process rigid, but that it’s a very good simulation with all sorts of issues coming up in the game that also happen in software practice.
Good to hear Gwyn!
If they weren’t brainstorming, what did they write their stories from? Did you provide them with some base criteria? Information about the resort itself?
You are right, this is definitely one of the more challenging games to facilitate. It takes a few times to really get the hang of it.