Agile Belgium: Agile games night III (10/09/2015)

Our agile games backlog for the evening contained:

  1. Two rooms and a boom
  2. Chocotoff mini games
  3. Amoeba Electric Fence
  4. Product owner value game
  5. Team drawing
  6. TDD Concurrent code

We’ve played the first five games.

Agile games backlog

Two rooms and a boom is a fun group game in which the bomb (red team) has to kill the president (blue team). The objective of the red team is to kill the president, the purpose of the blue team is to save the president. In each team, a leader is appointed who can exchange people (“hostages” ) between 2 groups. Check out the video below to learn about the game.

Agile games night

Chocotoff mini-games teach you about flow and bottlenecks in the flow. At each flow stage, a player can pass on a number of chocotoff (determined by rolling a die). Quite quickly, it becomes clear how bottlenecks are formed and how to further pushing “items” makes it worse! Limit your work in progress!

Agile games night

Amoeba Electric Fence is a team building game in which the entire team must cross over the top of the “electric fence”. The game builds on trust, and it takes some ‘physical’ effort and thought on how to cross each person. We’ve succeeded without injuries!

Agile games night

Product owner value game is a card game teaching how to refine a product backlog. The activities prioritise, decompose features (epics) into user stories, and refine user stories until ‘ready’ state for delivery. The cards abstract some ‘real world’ detail by predefining the effort and business value. The game focuses on understanding how backlog refinement works: refinement has a cost (don’t refine everything upfront); focus on steadily delivering value and choose wisely which items you deliver (taking into account the given effort and business value estimates). Read more about the game here.

Agile games night

Team drawing is a game to draw a particular “artefact’ in the group. One set can be played with a maximum of 10 people. Each person has a string to pull to guide the marker. Communication (in some form) is required to coordinate the drawing. Constraints can be introduced, such as no verbal communication, blinded sight, external noises, etc. The game shows how a group of people coordinates, and an observer can identify roles in the team (e.g. a leader, etc.).


Agile games night

Thanks to the people who joined! For more info about subsequent events, go to Agile Belgium on

Agile games night

product owner value game: refinement on-going

Product owner value game

Product owner value game

Dit game is ontworpen door Paul Kuijten en Dajo Breddels.

De context van de simulatie is om de rol en verantwoordelijkheden van een product owner beter te leren kennen en aan te leren. De simulatie focust zich dus op de backlog.

Wat is de rol van een product owner in een organisatie?

De product owner is verantwoordelijk voor het maximaliseren van de waarde van het product of service dat gemaakt wordt. De product owner zijn vehikel is de backlog: een lijst (1 bron) van alle requirements. De product owner heeft de autoriteit om te bepalen aan welke items het team eerst werkt (dit reflecteert zich in de rangschikking van de items in de backlog). Een product owner moet dus zeer goed weten wat de waarde is van items.

Het doel van de simulatie is dan ook uiteraard om maximaal waarde te creëren!

De simulatie maakt een abstractie, dus het volgende is gegeven:

  • Een backlog met een lijst van items (features/epics met een gegeven schatting van waarde en effort)
  • De features bestaan uit een aantal user stories (opnieuw met een gegeven schatting van waarde en effort)

Wat is product backlog refinement?

Refinement is de activiteit van het onderhouden van de backlog en het verder verfijnen van items in de backlog (door verduidelijking, toevoegen detail, verfijnen van waarde, verfijnen van inschattingen, etc.).

De simulatie

Initiële backlog (T-shirt sizing voor effort, waarde schatting in punten):

product owner value game: the backlog

product owner value game: the backlog

Refinement van 2 features (decompositie in user stories) (story points voor effort, nieuwe waarde schatting in punten):

product owner value game: refinement

product owner value game: refinement

product owner value game: refinement on-going

product owner value game: refinement on-going

Na 3 sprints (en toen was het game over):

product owner value game: value delivered

product owner value game: value delivered

  • Sprint 1: oplevering van feature 9 (één user story 46) bleek een goede keuze (aanvankelijk Small ingeschat, uiteindelijk 13 story points, maar met een hoge waarde: 1630 waarde punten)
  • Sprint 2: oplevering van user story 31, 40 en 22 (totale waarde 1560)
  • Sprint 3: oplevering van user story 1, 42 en 39 (totale waarde 1330)

product owner value game: results

product owner value game: results


  • 7 stories
  • Totaal effort: 46 story points
  • Totaal waarde: 4520 punten
  • Gemiddeld waarde / story point: ~98 punten

(statistieken om te vergelijken bij volgende uitvoeringen van het spel 😉

Wat zijn de learnings?

  • Het belang van het toekennen van een waarde aan items (en niet enkel ontwikkeling effort)
  • Het toekennen van waarde aan de hand van een schaal van punten)
  • Het afwegen tussen het verder verfijnen of het opleveren van items (enkel effectief opgeleverde functionaliteiten creëren waarde!)
  • De activiteit van refinement is niet gratis (dit kost capaciteit van het team)
  • Prioritisatie gebeurt niet enkel op basis van waarde, maar een combinatie van de verwachte waarde en benodigde inschattingen)
  • Als product owner moet je ook effectief lage waarde items durven weggooien 🙂

Mogelijke variatie op spel:

Een team dat speelt met kaartjes gegeven zonder een waarde schatting, en een team dat speelt met kaart met een waarde schatting. Op die manier zal met zeker het belang van waarde ondervinden.

Read more:

Game on!

getKanban3: some items deployed

getKanban: board game to learn and experience Kanban (software development)

getKanban is a board game that enables you to learn and practice Kanban in software development.


  • Kanban is Japanese. “Kan” translates visual and “ban” means card
  • Kanban is a process tool
  • Kanban works as a pull mechanism (as opposite to a push mechanism)
  • Kanban visualizes flow
  • Kanban limits work-in-progress
  • By limiting work-in-progress, bottlenecks in the flow will become visible

By visualizing bottlenecks, there’s an opportunity to improve the process flow (to remove the blockages, to remove waste, and as a consequence, to better match capacity with demand in the different stages of the flow)

Kanban applies control by measuring lead and cycle times – by improving the flow, you can enhance those lead and cycle times and optimize the flow to get work at a higher rate through the flow.

Kanban originates from lean manufacturing. A kanban card is a message it signals the depletion of goods (products, parts, inventory) to an upstream part of the process.

Conceptual diagram of a Kanban system Conceptual diagram of a Kanban system;

When received, the kanban card triggers the production requests of those goods. Therefore, the consumption of goods drives the demand for more needed goods – so kanban enables a demand-driven system (a pull system). A demand-driven system aims to minimize (or even eliminate) inventory, just-in-time production, higher flow throughput, and therefore aims companies to become more efficient. Lean manufacturing specifies the number of forms of waste and origins of waste.

Kanban comprises a set of straightforward rules, but (by years of application in lean manufacturing and almost a decade in software development) it has demonstrated its powerful ability to trigger self-reflection, collaboration, and process improvements. It has its roots in lean. Lean thinking’s pillars are respected for people and Kaizen.

The game

The game setup consists of a board, a stack of cards (backlog items with a specific value and effort to complete for analysis, development and test), several workers (analysts, developers, testers), and the necessary charts (financials and Cumulative Flow Diagram).

When playing the game, you quickly learn about the pull mechanism, the effect of limiting work-in-progress and use of the fast-track (expedite) lane and specific impediments (problems, interruptions …).

The start of the game is on day 9 of a project (the context is a web application development with a customer-subscription based revenue model) – so you enter the game with some items in progress. The game can be played in quick play (till day 15), standard mode (till day 21) and advanced mode (till day 24).

The initial state looks like this:

getKanban1: from left to right: blue indicates the backlog cards, black indicates the ready column, red indicates the analysis column, blue indicates the development column, green indicates the testing column
getKanban1: from left to right: blue indicates the backlog cards, black indicates the ready column, red indicates the analysis column, blue means the development column, green indicates the testing column

As you see, the work-in-progress limits are respected:

  • Maximum 4 cards (items) in the ready column (stage of the flow)
  • Maximum 2 cards in analysis
  • Maximum 4 cards in development
  • Maximum 3 cards in test
  • No maximum in ready to deploy
  • No maximum in deployed (which basically means “finished”)

Now it’s up to the team to evaluate the state of the board; the game is played as follows:

Assign workers to the different phases (analysis, development, test) – dice represent the workers. The number you throw with the dice gives you the number of effort units you can do for a particular phase, and you consume these on the items on that respective column on the board.

getKanban2: Arrows indicate the flow of items (via a pull from the right)
getKanban2: Arrows indicate the flow of items (via a pull from the right)

Items are pulled through the flow starting at the end of the flow (so from the far-right column: deployed). As you spend your effort points (dice points) on items, you will subsequently pull items through the flow, but pay attention to respect the work-in-progress limits.

At the end of the day:

  • Read the event card (the event may be positive or negative)
  • Add the numbers of the Cumulative Flow Diagram (CFD)
  • Tick off end of the day

Cumulative Flow Diagram

Cumulative Flow Diagram example, the colored lines indicate the different stages in the flow
Cumulative Flow Diagram example, the coloured lines indicate the different stages in the flow

A Cumulative Flow Diagram is a tool used in queuing theory. It shows the evolution of the flow in its different stages and the queue of items built up before each step. It shows the size of the queue (vertical line) and the lead time (horizontal line). Lead time indicates the time from request till delivery. Cycle time starts when actual work begins on the request and when the item is ready for delivery.

Billing time

Every 3rth day (day 9, day 12 …) it’s billing time.

getKanban3: some items deployed
getKanban3: some items deployed
  • You deploy read-to-deploy items
  • You cash-in your newly earned user-subscriptions (newly deployed features attract new customers) (new subscriptions gained are written on the back of each card)
  • You replenish the ready column with items from the backlog (respecting the work-in-progress limit) (because only every 3 days the product owner is available)

Expedite lane

The expedite lane is used to fast-track an item to delivery.

getKanban4: the expidite (fast lane) indicated in red, this lane has its own WIP limit
getKanban4: the expedite (fast lane) indicated in red, this lane has its own WIP limit
  • This lane has a work-in-progress limit of its own – an item in this lane does not count for the regular column work-in-progress limits.
  • Only items with a fixed delivery date flow through this lane
  • Delivering such an item too late results in a fine


You have several manipulations at hand:

  • Assign the workers (dices) – for example you can decide to assign a work outside his speciality (e.g. a developer to analysis or test); as in real life, a person working outside his expertise will be less productive.
  • Decide upon the number of items in the flow (the work-in-progress limit is an upper limit) (take care you cannot as such change the limit itself)
  • Prioritize the items in the backlog
  • Look at the effort required to complete of each item
  • Look at your metrics and use this data
  • And as such limit the work in progress, try to avoid bottlenecks, try to reduce lead times
  • Decide to deliver any fixed-delivery date items or not, if yes, decide the right time to handle these


getKanban5: blocker indicated in red
getKanban5: blocker indicated in red

A blocker might occur (via an event card). This will influence the flow. For example, it might break the work-in-progress limit (because a team has decided to do so). It might black a specific item (in the form of a block that must be resolved first).

More reading (more spoilers): Playing getKanban with an experienced team

Game over 🙂

getKanban6: end score
getKanban6: end score

Our gratitude to @AgileConsortium for hosting this event and @PatrickSteyaert for guiding the game.

Game on!