Main topic of this post is the mechanics of the one-day Agile process simulation, in continuation to the previous article, where I tried to advertise a value of Agile simulation workshops. However, for a complete picture I would recommend to combine suggested workshop structure together with the common recommendations similar to Doug Johnson’s “Top Ten Secrets for a Successful Workshop”.

First of all, Agile Simulation workshop is not the same thing to the Sprint Zero workshop. Sprint Zero workshops implies that we have already decided to adopt Agile delivery model. Then, obviously, we need a high quality format for starting new projects or refilling existing ones with a solid 6-12 months product backlog and draft release roadmap. Sprint Zero workshop is going to be a subject of the next article. Unlike Sprint Zero workshop, Agile simulator is a modeling of the hypothetical process with real artifacts, people and cases, at the time when the team and the customer are not sure whether they want to move to a new process or not.


The first and, perhaps, the most important step for any workshop - is planning. There are certain requirements that need to be taken into account during Agile simulator preparations:

1. Such event makes real sense if the real product owner can participate face-to-face with a R&D team. Preferably, a representative of the business, if there is no assigned person for that role yet.
2. Ask Product Owner to prepare a five to seven real features for the virtual backlog, but inform that only one feature will be virtually developed during the process.
3.Event facilitator should be an external person to the team, and to the Product Owner, for instance Agile Coach, or at least an experienced Scrum Master.
4. You have to sel ect a process for the simulation, such as Scrum or Kanban. It is very important to decide the total amount of exercises, their duration and sequence
5. To plan a nice and spacious place with boards, flip charts, markers and stickers. Also pizza, tea, coffee and biscuits will greatly help to add even more comfort to the participants as well as bring very good and collaborative atmosphere
6. To make sure that the event is planned for the team at a convenient time and in a place that does not attract people to their jobs
7. Ask the participants to come to the workshop early



Well, you are ready to start Agile simulation event. Event facilitator has to consider how to start in order to set up good and understandable context for further simulator exercises. It usually should take no more than 30-50 minutes, especially if there are already prepared handouts for participants and the most important information on a flip chart paper or even on the white board. Given good information radiators in place I would recommend visualizing the process with roles, artifacts and in a large scale. When starting bringing people to the context, do not try to explain all the theory at the very beginning. Agile simulation workshop has to be designed differently comparing to the traditional training. Keep in mind that interactivity is a core of the Agile simulation workshop. Theory can be introduced in a very simple form. Participants should be informed that more details will be opened at the relevant time-frame during the workshop. The goal for the first 50 minutes to make sure that all participants a) understand what is required of them, b) how they will get their questions answered c) provide a theory in the very simple form with little details d) agree the ground rules for agile simulation workshop.

Let’s move on. In my example, we have chosen to simulate the Scrum process. Therefore, as a first step I suggested my attendees to elaborate the very first artifact which is called Product Backlog. For that reason I asked Product Owner to visualize his backlog of 5-7 features on a flipchart paper. This exercise was split into two parts where for the first part lasted for a 30 minutes, including 5-10 minutes to explain the theory of what is the Product Backlog and how it is used in Scrum process. By the way, almost every new exercise begins with the theoretical infusion where I’m explaining key things, why we do it in scrum and what is expected fr om the participants. I was trying to finish each exercise with a brief explanation of how the practice or a discipline might be different in a real life.


Another 30 minutes were allocated for the initial review and prioritization of the features so that at the end we’ve got prioritized backlog. The team together with Product Owner sel ected the topmost item fr om the product backlog for the next exercise.

The next stage was called backlog grooming. As well, we broke it into two parts. On the first part of grooming team asked questions to the Product Owner. All the answers become acceptance criteria for the user stories. I found very interesting thing - since the feature was real, and the team had seen it for the first time, it turned out that this exercise also brought some benefits. The second part of grooming was designed to write tests for the acceptance criteria. For this exercise I chose the technique which is called Specification by Example and by using this technique we worked out a matrix of the acceptance tests. The entire grooming exercise took at least two hours, and then we interrupted for eating pizza.

The next half of the day we started from the virtual sprint planning. First part of the planning event team with the Product Owner was discussing the definition of done (DoD) for the selected features. Also, the Product Owner shared how he would accept feature on the demo meeting and what kind of tests is worthy paying attention to. In the second part of the planning the team created another scrum artifact which is called Sprint Backlog which is consisting of virtual development tasks estimated in hours.


After the planning we did a few day iterations, wh ere a team of 5-10 minutes was drawing on paper a rough implementation of the sprint backlog tasks. We have learned how to use scrum board, burn-down chart and to conduct daily scrum meetings.


At the end of the agile simulator workshop, all participants stayed for one hour retrospective. Everyone has shared what they liked in the simulated process and what was not so good. What are the potential risks might take a place in the implementation of a similar process at full scale with some considerations around how to work with risks.


The story is coming to the end. Decision was made by the customer to switch to a new process with a confidence that the Luxoft team can support Agile transformation. The simulator has helped to see the obvious advantages of Scrum process. Two months later I conducted full-scale Sprint Zero workshops for the same team. But that's another story, which I’ll cover in my next article.