A complete agile simulation in 75 minutes



There are many different processes that apply the values contained within the Agile Manifesto, including techniques like scrum, eXtreme programming, and Kanban. Indeed, the greatest strengths of the agile processes—the flexibility and propensity to adapt to a given situation—also make them more difficult to clearly define. Sometimes, that which is not clearly stated can be just as important as those mechanics clearly enumerated. The purpose of this paper is to describe the fundamentals of an agile project and how to communicate them within a short time period using a project simulation.

The use of games to educate and reinforce concepts is not new to the agile community. Indeed, in 2001, Vera Peeters and Pascal Van Cauwenberghe pioneered the development of the “XP Game” to help educate teams about the values and concepts of eXtreme programming. That exercise has gone on to become the foundation for many agile training classes (Peeters, 2006). Our own experience conducting training classes reinforces this perception, as many of our own classes lean very heavily on the use of games and simulations. Although lectures can communicate information, the challenge when conducting an introductory session to a new concept like agile project management is twofold. First, there are the transfer and acquisition of skills required for people to execute the mechanics of an “agile project.” Second, there is a distinctly different perspective required to run a project in an adaptive manner to focus on business value and respond to change.

In many cases, this is a very difficult concept to explain and it is frequently wrapped in emotions and ego. A disruptive change, like the introduction of agile practices to project management, can engender resistance of an emotional nature; as such, it cannot easily be explained away, because people’s concerns are usually emotional, not logical. No amount of presentations, discussions, or statements of fact will be very effective in these situations, and this is where the use of an exercise or game can be advantageous.

The Benefits of Games and Play

Simply stated, games are used within a training environment to create positive emotions for the purpose of helping people adopt new practices. Although still an emerging field, research is beginning to reveal the significant effects of positive emotions. Barbara Frederickson pioneered the thesis that positive emotions can be profoundly important in the acquisition of new skills and behaviors. The best example of this would be childhood activities characterized by play; however, research has shown ample benefits for adults as well. Games and play, as parts of a training regimen, are used to exploit these benefits and help people adjust to change on both an emotional and mental level. Specifically, we will explore three areas: broadening the scope of attention, broadening the scope of action, and building experiential resources (Frederickson, 1998).

Numerous studies have explored the effects of highly charged negative emotions, such as stress or fear, and their impact upon a human beings scope of attention. The general pattern is that these emotions cause a narrowing of focus, best demonstrated when witnesses testifying in court can describe details of an assailant’s gun, but not the person’s face (Easterbrook, 1959). Applied to project management, we can see how high stress situations would lead to a similar narrowing of focus where people become consumed by following mechanical steps or producing artifacts to the detriment of the actual project outcome. This isolated behavior transcends just project management and can be observed in the behavior of many professionals under high levels of duress. People replace a focus on the project with a focus on doing just their part. This can lead to incongruent hand offs between individuals, inefficiencies, gaps in interdependencies and other challenges. Sadly, for managers who are highly dependent upon command and control techniques, increasing pressure will only make this challenge worse.

For a team to run an adaptive project, it must see the “forest for the trees” in order to understand the context of the situation in which they are running a project. Recent research suggests that the impact of positive emotions cannot only negate the narrowing of attention described, but also expand people’s range of attention (Derryberry &Tucker, 1994). This broadened attention span helps people make broader comparisons and more readily identify trends and patterns. These are the critical skills for agile projects that are expected to respond to change. Without an ability to identify patterns and trends, this adaptability would be of minimal value. The use of a game in this context is to help practitioners experience a broader level of attention, which is only furthered by simulations and games that compress what would be months of activity into an hour or two simulation, providing the ability to see the impact of decisions much sooner and more clearly than people may in actual project management situations.

Adopting the values of responsiveness to change and collaboration embodied by the Agile Manifesto frequently requires people to change their behaviors and the available actions used in a given situation. Similar to the challenge discussed regarding scope of attention, negative emotions will narrow the set of actions one will consider. The best example of this would be the “fight-or-flight” response that animals and humans exhibit when in a state of fear. Even more interesting, research has shown that people experiencing positive emotions exhibit a much broader range of behaviors than those in a neutral or negative condition. This concept is best demonstrated by using Duncker’s candle task, wherein people are given a box of tacks, a candle, and a book of matches. They are then instructed to mount the candle to the wall in a way that it will not drip wax on the floor when lit. Participants can succeed by broadening their perspective of the box of tacks to use the actual box as a holder and mount that to the wall. In various situations, researchers found that subjects with positive emotions were more likely to identify and implement the solution than those people who had experienced negative or neutral emotions (Isen, 1987).

This lines up very closely with our own desired outcomes when introducing agile concepts. Our goal is to help people broaden their set of actions, identify creative solutions, and begin to experiment and this is beneficial on two levels. First, it helps break down the barriers created for arbitrary reasons and provides participants in a simulation with the impetus and motivation to try things they would not normally do in the workplace. In the case of our agile simulation, people will be more likely to have team members switch roles based on the immediate need, adjust scope based on their understanding of what will deliver the most value, and time work to maximize the value delivered based on opportunities to implement early. Beyond the case of this simulation, individuals on agile projects need the ability to constantly broaden their set of actions to try new, creative approaches to solving problems. Experience dictates that no two projects are the same. Even within the same business, context changes over time, individual team members vary, and a myriad of other minor variables fluctuate, such that no past experience will ever serve as a perfect barometer for the next. This is a valuable perspective, and it manifests in the belief that there is no single “agile process.” A cursory review of methods such as scrum, Kanban, and even XP will find that they leave a significant amount of flexibility to incorporate activities not based on the circumstances. In this type of environment, project managers who are able to experiment with a broader range of activities will thrive.

Lastly, we come to the benefit of building experiential resources. A large body of research has shown how children undertake different forms of play to learn and build skills they will use later in life and this concept also applies to adults. When introducing new techniques like agile project management, our goal is to create a change in people’s behavior. The relatively safe format of a simulation or game allows people to practice these new skills in an environment that should be fun and free of the pressure of a project. This play environment allows people, freed from the pressure of their immediate project work, to practice actions they would not be able to comfortably undertake in a real situation.

These dynamics add up to a powerful case for using games to communicate the mechanics of agile project management, as well as offer an environment for individuals to experience and explore it. As discussed earlier, there are a number of games that have been developed within this space, as well as many games originating from other sources but applied to this field. The game offered for this conference is designed to focus on project and product management so that project managers can experience the planning and execution on a complete project. Teams have the flexibility to change work assignments, select the most important work, and adapt their plans as the simulation advances.

Fundamentals of the Game

When designing a game, there are two approaches one can take. A game may be designed with a specific outcome; this would be a closed game, like the candle game discussed in the prior section. A closed game may have a powerful lesson, such as how one should broaden the scope of what he or she considers part of a scenario, but generally, there is a distinct lesson. Or you may design an open game, in which there are a number of different lessons people may learn from, depending on how the situation presents itself and the individual actors. Military war games are an excellent example of open games because there is no pre-determined outcome. In fact, they are designed to broaden our understanding of a complex and ambiguous situation.

The agile simulation game developed and presented as part of this conference is a combination of an open game and a closed game. People will compete to maximize the value they can deliver, and there are certain closed lessons that people will learn; however, the game has some flexibility in how different things are scored, as well as what events play out. Within the rules for this game, some fundamental mechanics are fixed, whereas other components may be customized based on the circumstances of a specific simulation. Customization can be very important, because it allows the simulation to better represent a real situation, making it more relevant, and focusing potential lessons learned on a situation that is more accessible for those playing the game. For the purposes of this conference, our simulation is based on a project to build out a website, assuming that most people are familiar with IT and general website functionality.


  • Goal: people will form teams that will simulate a software development project. The goal will be to build an application realizing the most value possible.
  • Team size: people will play in teams of 4 to 10 individuals, with team sizes roughly evenly distributed
  • Game mechanics:
    • Within each team, people will be given the following roles:
      1. Product owner: selects the stories for work and sets the immeidate priority. They will be responsible for tracking business value realized
      2. Scrum master: facilitates group interaction and ensures the process is followed for the game
      3. Developers: may do any work, but when they do development work, they roll two dice
      4. Testers: may do any work, but when they do development work, they roll two dice
      5. Analysts: may do any work, but when they do analyst work, they roll two dice

    Note: In this case, we have selected three team member roles: developer, tester, and analyst and these may be changed based on your circumstances. You should not change the product owner role, because that is a critical one. The “scrum master” role is also critical, because he or she will help keep score for each team, allowing the game to be scaled to a larger group than would be possible with a single facilitator

    • Each team will have the same “product backlog,” which is a functional work breakdown structure for the product to be built. Each work item will have three tasks: analysis, development, and testing; these will have numerical values, indicating their best estimate of how many hours of work each task will take to complete.
    • Based on the backlog, the team will plan their first release, which is comprised of two sprints, with each sprint comprised of five days

    ▪ The release plan consists of a prioritized list of work items the team plans to do within each sprint, as well as a forecast for how much value they will be able to deliver for the release.

    Note: The precise length of time may vary, depending on how long you have, the size of your group, and how quickly people are going. The more rounds of play, the longer it will take, and the simulation faces the risk it may become too long. Facilitators may also increase the movitation to work quickly by rewarding the team that can finish each round as quickly as possible or simply imposing a time box on each round of play.

    • Mechanics for a sprint

    ▪ A sprint will be executed by conducting one round or “work” for each day within the sprint.

    ▪ Each person selects what task they will work on for the day, indicating what tasks they will do for that day.

    ▪ Each person then rolls their dice to determine how much work has been completed and updates their tasks acordingly. If a task is finished with less than the total amount of their roll, they may then apply the remainder to another task. There is one limitation requiring that a person can only work on one type of task within a given day.

    ▪ The team will repeat this process 5 times to simulate a 5 day sprint

    ▪ The ScrumMaster is responsible for managing the list of tasks for the sprint and reporting on what is completed or not.

    ▪ The Product Owner may indicate the priority for completing work and is responsible for reporting how much value is delivered each sprint.

    ▪ The team that can finish their sprint first will gain a bonus for that sprint by being allowed to play a sixth day as a reflection of how quickly they were able to get through their sprint.

    ▪ The facilitator may impose a “time box” based on how quickly each sprint progresses. The point of the time box will be that after a designated period or time, the sprint is over and teams must stop playing. Whatever work has been completed will be credited, but any days they were unable to simulate are lost due to inefficiency of their planning.

    Note: A facilitator may want to reserve this rule and only reveal it after the second sprint because this will give him or her a better understanding of how long each team is taking to complete a sprint.

    • Product backlog management

    ▪ Teams will manage their work through a product backlog. This will encompass a series of work items, hereinafter referred to as “stories,” outlining the work to be done

    ▪ Each story will have an explicit amount of business value

    ▪ Each story will have estimates for the three tasks they contain (analysis, development, and testing)

    ▪ Each story may have a dependent story that must be completed before it can be done

    ▪ There may be some “non-value” stories to do things like refactor code or investing in new techniques. These won’t deliver any immediate value, but will do things to help the team perform faster.

    ▪ Stories will be organized along a “story map” that shows where they fit into the product. For this simulation, we will use an online restaurant reservation system (e.g., Open Tables) as an example. The story map will consist of the following steps:

    1. Find a restaurant

    2. Learn more about a restaurant

    3. Book a reservation

    4. Manage my reservations

    5. Manage my account

    • In order to realize value, a team will need to deliver some functionality across all dimensions, thereby showing the reality of building a product up over time and managing the risk of delivery (if they get to a release, but haven’t delivered one of those capabilities, they will not be able to realize any value)

    • Changing variables – as the game advances, teams will discover different things and face impediments and other significant situations impacting their project.

    ▪ At the beginning of each sprint, and halfway through each sprint (beginning of day 3), the team must draw a card from the deck

    ▪ Each card will introduce a change or issue, such as:

    • New technologies – with the emergence of new technologies, some stories may become much easier later in the game

    • Impediments – issues may emerge that impact the team’s ability to do work. These may be blocked to individual resources or mandates that influence the way team members may behave (e.g., only testers may test)

    • New requirements – with the marketplace maturing as teams develop their product, new user stories may emerge that will yield higher value than the work originially planned.

    ▪ Based on these changes, teams may adapt their sprint and release plans as they deem appropriate.

    ▪ The deck of cards may be a list of random events pulled in no order by each team or they may be a choreographed set of events.

    For purposes of this specific game, we will use a choreographed set of cards, such that every team faces the exact same situation. This will help focus the discussion on a few key lessons learned specific to project management.

    • Scoring

    ▪ At the end of each sprint, teams will add up how much work they have completed and how much is remaining to manage a product release burn down.

    ▪ At the end of the first release, any team that has a functioning application may launch and get value. Those who don’t have a complete application will not be able to launch their product and realize any value. All work delivered in the first release (as opposed to the second) will get a 20% first mover advantage.

    ▪ At the end of the game, teams will add up the value they were able to deliver, and the team with the most value delivered will win

Key Learning Objectives

As a fairly open game, this Agile project simulation is open to many lessons learned. However, there are a few key ones we would like to highlight. These should drive the debrief discussion after game. When facilitating a game such as this, it is important to keep an open mind. There is an element of chance based on the roll of the dice that may direct the game in different directions than others. If a facilitator tries to debrief the game based on a prescriptive formula, the conversation may feel contrived, denying the participants a valuable opportunity to discuss and reflect upon their own learnings. This is a balancing act the organizer must maintain. By having a few key points to discuss, as well as watching the team’s play, they should be able to pose thought provoking questions and offer observations to help team members reflect upon their own behavior, what worked and what they could have done differently. Towards the goal of arming a faciliator with a few key patterns to watch for, we offer the following list of lessons.

Focus on Business Value

This lesson is almost immediately learned in play, but people may not notice it. The moment the goal is fr amed as the team to realize the most value, the entire team begins to plan how to deliver the most value, not how to conform to a plan. People may not even notice the change in behavior, but it’s worth discussing. The role of product owner would be the customer. How did the team interact with their customer? When changes emerged, did they dwell on change control or adjusting to continue to maximize value? Did this feel different than their normal projects? Generally speaking, an agile team will experience a high level of collaboration due to this shared objective. The team’s goal is not to meet their plan, but to maximize value. It may also be worth looking at the original plans and seeing how they ended compared with the original plan. This shared purpose leads to the next lesson.

Work as a Team, Not Individuals

In addition to cooperating with the product owner, many team members will probably find them moving beyond their silos to do work that is not traditionally within their purview. The game is set up to offer a comparative advantage for specialists doing the work of their specialty. However, in spite of this 100% productivity advantage, you will see teams that will assign developers to test, testers to do analysis and other similar situations. This is fertile ground for conversation, as it begins to challenge traditional notions of specialization within teams.

Manage Risk Up Front

Each team will face a major risk, which they will reach in the first release and not have a product that spans all functionality, thereby denying them a lucrative first mover advantage. Some teams may not see this and will prefer to pursue features based on a quick cost-benefit ratio, end up with a program that has a lot of important features, but that can’t be released because it is not complete. Teams must manage their product intelligently and one key behavior is that teams can confront risk early on. A team may do just enough stories to ensure they can release, thereby mitigating this risk, and then pursue some of the most lucrative features. Even if they hit a major impediment, they will have already locked in their ability to release.

Minimize Work in Process

Partially done work realizes no value. Teams may be tempted to take on massive amounts of work in order to ensure their specialists are always able to work in their most productive domains. However, work is frequently not evenly distributed, and the method of doing work (rolling dice in our game) is highly variable. There is no explicit penalty for having a lot of work in process, except that it may bog down the team’s ability to execute quickly. It may also lead to wasted effort, because any work incomplete after the second release has no value.

There is No Perfect Approach

Agile projects assume that no two situations will ever be identical. Therefore, attempting to proscribe a perfect solution is always fraught with risk. Facilitators should be confident enough to share this perspective and acknowledge that individual teams may come up with their own ways for doing work more effectively. It would be worth highlighting which teams executed the fastest, delivered the most value, or in other ways performed in an outstanding manner. Just as teams modifying their behavior to improve their performance in the game, so should they be able to do with an actual team at work. Another important concept is that there was no manager telling them how to improve. Each team understood the objective and jointly owned their process.


There is no perfect representation of a complex project or other system. Any game, no matter how elaborate, will simplify some concepts and require some level of suspension of disbelief. This is a potential liability when using a game to convey complex concepts but it is also an asset. Although a simulation will invariably neglect some concepts, it will focus on others, allowing people to gain insights about the point of focus. The simplification also allows people to see larger patterns. In the case of our agile simulation, we condensed two releases of a product into 75 minutes, allowing people to see, within a single session, the implications of prioritizing work, and how an initial plan may need to be adjusted to get the best outcome. Some people may specifically hone in on the disconnects between the game and reality. Perhaps it is not realistic that testers will never be able to do development work, and gaps like these may also be worth exploring and discussing as a better way of understanding our current system and the implications of that design.

Ultimately, the measure of a good simulation or game will not be reaching some preconceived conclusion, but rather in helping the participants. The goal of a game like the agile simulation is to help introduce the mechanics of an agile project and give people an opportunity to practice paths of action within that domain. If people feel the game is not possible or is not consistent with their own environments, then these 75 minutes were well spent in identifying the challenges that will need to be confronted should that organization decided to pursue agile. Lastly, although this simulation is an introductory exercise, games, and simulations should not be considered purely within that purview. The points of games like these are to broaden the perspectives that are applicable to people well beyond first introductions. As such, we should consider games like these as tools to be used with different audiences at different points in time.


Derryberry, D., & Tucker, D.M. (1994). Motivating focus of attention. The heart’s eye: Emotional influence in perception and attention. San Diego, CA: Academic Press.

Easterbrook, J. A. (1959, May). The effect of emotion on cue utilization and organization of behavior. Psychological Review 66(3) 183-201.

Frederickson, B. (1998). What good are positive emotions?” Review of General Psychology (Vol. 2), Washington D.C.: Educational Publishing Foundation

Isen, A.M. (1987). Positive affect, cognitive processes and social behavior. In L. Berkowitz (Ed.), Advances in Experimental Social Psychology. New York: Academic, 203-253

Peeters, V. & Van Cauwenberghe, Pascal (2006). XP Game Acknowledgments, Retrieved from http://xp.be/xpgame/acknowledgements.html.

©2010 Brian Bozzuto & George Schlitz
Originally published as part of Proceedings PMI Global Congress 2010 – Washington D.C.