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

Tempo: 30-60 mins
Ingredientes:

  • Cartões de índice (fichas A5 ou A6)
  • Recursos para cada time: papel para a construção do folder, cola, réguas, tesouras, marcadores
  • Revistas para o recorte de imagens
  • Quadro para status da iteração (quadro branco, parede, etc.)

Receita:
Em equipes de quatro ou mais, os participantes devem concordar em torno de uma lista de desejos sobre o que eles gostariam de ver em um folheto para o resort de seus sonhos. Usando as fichas, as equipes devem escrever histórias de usuário para o folheto (por exemplo, como um pai, eu quero uma atmosfera amigável para crianças para que eu possa me sentir confortável em trazer as crianças; como um dono, eu quero anunciar uma oferta especial para que eu possa atrair mais veranistas , etc.). O Product Owner eleito da equipe deve, em seguida, priorizar cada história, colocando as cartas em ordem de importância.
As equipes preparam-se para uma iteração de 12 minutos (três dias de quatro minutos) selecionando as histórias que eles pensam que podem desenvolver na primeira iteração. Para cada história selecionada, a equipe define os critérios de aceitação (definição de “feito”) a fim de clarificar os requisitos e extrair as tarefas (por exemplo, encontrar imagens de praia, escrever o nome do resort no folheto, criar o layout, etc.). Cada tarefa é colocada no quadro de status da iteração na coluna “Agendado” e então a iteração começa.

Cada dia da iteração deve começar com uma reunião diária rápida, onde os participantes movem as tarefas para a coluna “Concluída” e se voluntariam para as tarefas, movendo-os para a coluna “Ativa”. Todas as tarefas bloqueadas são movidas para a coluna “Bloqueada”. Após a reunião diária, cada membro deve começar a produzir de acordo com os critérios de aceitação até o término dos três dias, finalizando a iteração. Uma iteração deve terminar com a revisão do seu progresso e uma retrospectiva, onde que cada equipe listas que eles fizeram bem e o que eles podem melhorar para a próxima iteração. Repita iterações conforme necessário.
Pontos de aprendizado:

  • Essa é uma ótima mini-simulação de Scrum. Ela provê a cada participante, senso de controle e visibilidade sobre todo o trabalho sendo realizado.

Duración: 30-60 minutos
Ingredientes:

  • Fichas de Cartulina
  • Suministros para cada Equipo: cartulina, pegamento, regla, tijeras, marcadores
  • Revistas para recortar imágenes.
  • Tablero de Control (pizarra, pared, etc.)

Receta:
En equipos de cuatro o más,  los participantes deben ponerse de acuerdo sobre una lista de deseos sobre lo que les gustaría ver en un folleto para su Resort ideal. Usando las Fichas, los equipos deben escribir historias de usuario para el folleto (por ejemplo: Como padre, quiero un ambiente agradable para los niños, para que pueda sentirme cómodo llevándolos; Como propietario, quiero anunciar una oferta especial para poder atraer más turistas; etc.) El equipo elige el Product Owner, que luego debe priorizar cada historia poniendo las fichas en orden de importancia.
Los equipos se preparan para una iteración de 12 minutos (tres días de 4 minutos) mediante la selección de las historias que ellos piensan que pueden realizar en la primera iteración. Para cada historia seleccionada, el equipo define los criterios de aceptación (definición de “Listo”) con el fin de aclarar los requisitos y extraer las tareas (por ejemplo, encontrar foto de playa, escribir el nombre del resort en el folleto, crear un diseño, etc.). Cada tarea se coloca sobre el Tablero de Control de iteración en la columna “Programado” y se inicia la iteración.
Cada día de la iteración debe comenzar con una rápida reunión Scrum, donde los participantes mueven las tareas terminadas a la columna “Completo” y se comprometen con nuevas tareas moviéndolas a la columna “En Ejecución / Activa”. Cualquier tarea bloqueada debe ser movida columna “Bloqueado”. Después de la reunión de Scrum, cada uno debe empezar a producir de acuerdo con los criterios de aceptación durante los tres días hasta el final de la iteración. Una iteración debe terminar con una demostración de sus progresos y una retrospectiva, en el que cada equipo liste lo que hicieron bien y lo que pueden mejorar para la siguiente iteración. Repetir iteraciones según sea necesario.
Puntos de aprendizaje:

  • Esta es una buena mini-simulación de Scrum. Se proporciona a cada participante sentido de control y visibilidad sobre todo el trabajo que se está realizando.

Время: 30-60 минут

Материалы:

  • Карточки
  • Для каждой команды: цветная бумага, клей, линейки,
    ножницы, фломастеры
  • Журналы для вырезания картинок
  • Статус итерации (на доске, стене и т.п.)

Правила:

В командах из четырех или более человек, участники должны составить список того,
что они хотели бы видеть в буклете, описывающем их идеальный курорт. Затем команды
на карточках должны написать User Story для каждого пожелания в их буклете(например,
“Как родитель, я хочу, чтобы отель был рассчитан на детей, и я мог бы спокойно брать
с собой ребенка”; “Как владелец курорта, я хочу разместить информацию о действующих
акциях, чтобы привлечь больше отдыхающих”; и т.д.). После этого в команде выбирается
Product Owner. Он расставляет приоритеты, раскладывая карточки в порядке важности.

После этого команды выбирают карточки для первой итерации, определяя таким образом,
что, по их мнению, они смогут сделать за 12 минут (три 4-x минутных дня). Для каждой
выбранной User Story, команда определяет критерии готовности, чтобы уточнить требования
и разбить их на задачи (например, найти изображения пляжа, написать на буклете название
курорта, определить расположение элементов на странице, и т.д.). Каждая задача размещается
на доске в колонке «Запланированные», и начинается итерация.

Каждый новый день итерации начинается с короткой встречи (Scrum meeting), где участники
перемещают задачи в колонку “Законченные” и выбирают себе новые задачи, перемещая
их в колонку “Активные”. Любая заблокированная задача перемещается в колонку “Заблокированные”.
После Scrum митинга каждый член команды начинает работать над своими задачами, стремясь
выполнить всё в соответствии с критериями готовности. Так продолжается до истечения
трех дней и конца итерации. Итерация заканчивается демонстрацией результата и ретроспективой,
где каждая команда говорит о том, что, как им кажется, они сделали хорошо, а что
можно было бы улучшить в следующей итерации. Если нужно, повторите итерацию.

Выводы:

  • Это хорошая мини-модель Scrum методологии. Она дает
    каждому участнику чувство прозрачности процесса и контроля над выполняемой работой.

Опубликовано Don McGreal
Перевод Tatyana Yanush

14 thoughts on “Resort BrochureFolheto de ResortFolleto de ResortБуклет “Идеальный Курорт”

  1. Hi,

    I am curious about scaling this activity down for a team of only 3 – I want to facilitate this for my newly agile communications unit, which consists of 4 people (myself included). Can this be done? Any tips for success?

  2. Hi Don, finally got the chance to play this one… I did decide to start with the visioning and backlog creation first and played 3 iterations of 5 minutes. The resort brochure worked out very well, even the transition from regular stakeholder to PO. the only thing I would leave out next time are the magazines. I felt they actually limited the participants in their creativity. Next time I will add more colored paper, markers and tape instead. Thank you!

  3. I ran this last week with a team of marketing people. Guess what professional brochure we got! With a clear disposition, color theme and u know it. The vision turned out to be a brochure for “Dinkies” (and gay target group) to come to Sweden for gourmet traveling. The Swedish Tourist Board could for sure use this concept!

    Lots of fun! The vision was hard work, I think they realized how extremely important it is to have
    – a clear vision
    – a product owner who has the last word (the vision was first under very much debate until the ScM – facilitator got in and asked the PO to decide)
    – a clear target group
    – focus – I tried to interrupt them sometimes by asking some of the team members to join other meetings and projects. The PO stopped me. And the team members asked me to go to the PO. Great!
    – stop talking and just start producing good enough prototypes sometimes when having a demo or daily standup coming..

    They seemed to really getting the point of Scrum, although none of them were developers.
    Very ambitious on the user story writing they were, I had to stop them although I liked the idea of them blooming out in creating user stories.
    Sorry we didn’t got the time to make a second iteration.

    The daily stand ups extremely important to keep them focused and going forward.

    I very much recommend this for business and marketing people.

    The hard thing is now – to make it happen at home.

  4. I have now run this twice, both times with two groups of six people in each. I tried to take them through the process of running a couple of sprints, with two “days” in each, with planning, reviews, retrospectives and daily stands ups.

    Both times I’ve found one group follows my plan well, the other goes through the motions and doesn’t break down the tasks very well. I am sure that over time I shall learn to facilitate this better so that team is given more guidance and support.

    I find I need to be responsive and sometimes skip the daily stand-up because the groups have gone off and done it anyway in the planning stage. I feel I need some tweaking here to make the flow more ordered. However this can be useful in the retrospective when they say they had poor communication and I can highlight if they had the daily scrum maybe it would have been okay.

    My slides can be viewed: http://www.slideshare.net/gupster/agile-resort-brochure-game-july-2011

  5. Wow, I’ve just been the organizer of this game for 2 small groups of 5 people and I enjoyed it a lot.

  6. Don, I have 2 hours for everything, so your timeline is helpful. Given I won’t be able to walk around and observe all the teams all the time, I’m thinking of spotlighting one team for each new ceremony, having everyone observe, then off they go to try themselves. Or at least, get one team started, have everyone watch then try themselves.

  7. Good luck Gerry! How much time do you have in your session?
    I also use slides to help frame each step. And with that many people, make sure you bring a whistle or something. 🙂
    Here is a copy/paste from a recent comment I made on my Agile2011 session about timing for this game. It may be useful:
    ———-
    We usually put aside ~120 minutes in the classroom. But I have also done this as a 90 minute presentation where, to save time, I pre-populate their backlog (but team PO still prioritizes) and I provide them with ready-made task boards and burn-downs (ScrumMaster ensures they are being updated).

    Here is a rough breakdown of each activity:
    intro – 5 min
    roles of scrum talk – 5 min
    prioritize backlog – 5 min
    sprint planning talk – 10 min
    sprint planning (commitment + task breakdown) – 10 min
    day 1 – 3 min
    daily scrum talk – 5 min
    daily scrum – 5 min
    day 2 – 3 min
    daily scrum – 5 min
    day 3 – 3 min
    demo talk – 5 min
    demo – 10 min
    retro talk – 5 min
    retro – 5 min
    conclusion – 5 min

    It is worth noting that I start by telling them they have multiple sprints, but we only ever end up doing 1. This helps reenforce the idea of sprint commitments and of producing something shippable by the end of each sprint. They get the idea after 1 sprint anyway.
    ———————

    Let us know how it goes Gerry! I’d be happy to discuss further with you, this game is one of the more challenging/rewarding/powerful games. One of my favorites though. 🙂

    Don

  8. I am about to run this game at a conference, where I’m expecting up to 10 or 11 groups of 6 seated at tables. Am I nuts or what??? 🙂

    Thanks for the suggestion to not write as user stories or require acceptance criteria. When scaling large, simple is better.

    Some other ways I plan to deal with scale:

    – handout for each team, explaining game and steps
    – before starting, walking through game by showing steps on slide deck, including a partly made brochure
    – using slides to show where we are at, what people are supposed to be doing
    – using music to indicate when each sprint starts/ends

    Wish me luck!

  9. 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.

  10. 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.

  11. 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.

  12. 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

  13. 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?

Comments are closed.