Featureban

Featureban is a Kanban simulation game created by Mike Burrows. In teams of 3 to 6, participants move post-it notes representing features on a simple board, at the pace of rounds that symbolise days. The game experiences three successive situations: visual management alone, adding work-in-progress limits, and then introducing flow metrics. It serves to concretely understand why limiting work in progress, addressing bottlenecks, and measuring lead time improves delivery capacity.

Walkthrough

1. 1

   Set the framework and form teams

   10 min

   The facilitator presents the intention: "We are going to simulate a Kanban system, not trying to win against others. Pay attention to what happens to the flow, the bottlenecks, and your way of collaborating." They form teams of 3 to 6 people, each with a simple board and post-it notes representing features. They clarify that a round of play represents a day and that each player will act in turn. Participants gather around their board and visually identify the areas where items will start, progress, get blocked, and finish.

   Tip — Avoid over-theorising Kanban at the start: the simpler the initial instructions, the more striking the contrast between iterations will be.

2. 2

   Explain the common mechanics of rounds

   10 min

   The facilitator gives the rule that will remain at the heart of the game: at each round, each player draws a result at random with a coin or a card. "If the result is favourable, you advance one of your items or start a new one. If the result is unfavourable, you must block one of your items and start another." They check that everyone understands that a blocked item remains visible and does not progress until it is unblocked according to the decisions allowed in the iteration. The teams do a mini trial round if necessary, without counting the results.

   Tip — Have a participant rephrase the rule: the most common confusion concerns the unfavourable result, which indeed requires blocking and then starting something else.

3. 3

   Iteration 1 — Visual management only

   15 à 25 min

   The facilitator launches the first simulation: "For this iteration, you only have the visual board. There are no work-in-progress limits and you strictly apply the rule of chance." Each day, players take turns: favourable result, they advance an existing item or create a new one; unfavourable result, they block one of their items and start another. The facilitator deliberately allows the system to become overloaded with work in progress and bottlenecks, without correcting behaviours. At the end, each team observes their board: the number of items started, blocked items, completed or uncompleted items.

   Tip — Do not save the teams too early: the educational interest comes from the visible discomfort when the board fills up and everyone continues to open new work.

4. 4

   Short debrief of iteration 1

   10 min

   The facilitator asks the teams to describe their system factually: "What do you see on the board? Where is the work accumulating? What is blocked?" They still avoid solutions and bring out the observations: numerous work in progress, visible bottlenecks, low sense of control. Participants quickly compare their boards without seeking a ranking. The goal is to connect visual management to its limit: it makes the problem visible, but does not solve it by itself.

   Tip — Use the board as evidence: point to the post-it notes, the overloaded areas, and the bottlenecks rather than discussing general impressions.

5. 5

   Iteration 2 — Add WIP limits

   20 à 30 min

   The facilitator introduces the second rule: "This time, your system has work-in-progress limits. When a limit is reached, you cannot simply start more work: look for ways to help advance or unblock the existing items." Teams define explicit limits on their board before restarting the simulation days. The mechanics of chance remain the same: favourable, advance an item or start a new one if the limit allows; unfavourable, block one of your items and start another only if the system permits. Participants then experience the necessity to help each other to circulate work instead of piling up new tasks.

   Tip — Ask teams to write the limits directly on the board: an oral limit is quickly forgotten when the pressure of the game increases.

6. 6

   Short debrief of iteration 2

   10 min

   The facilitator compares the experience with the previous iteration: "What did the limit prevent you from doing? What did it force you to do?" Participants identify changes in behaviours: discussion, help, attention to bottlenecks, prioritisation before starting. The facilitator emphasises that the WIP limit is not an administrative constraint, but a mechanism that makes the flow negotiable and collective. Teams note what has improved and what remains difficult.

   Tip — Emphasise useful frustrations: if someone says, "I could no longer start," ask, "What did you do instead?"

7. 7

   Iteration 3 — Introduce flow metrics

   20 à 30 min

   The facilitator adds the final layer: "We will now measure the system, not just observe it. Track the number of items in the states on the board to feed a cumulative flow diagram, and note for each item its start day and arrival day to observe lead time." Teams replay with visual management, WIP limits, and the same rule of chance. At regular intervals or at each simulated day, they record the necessary data: volumes by state, completed items, start and end dates. The facilitator helps read the trends without turning the exercise into a statistics course.

   Tip — Keep data collection light: it is better to have a small amount of accurately kept data than tables of figures that interrupt the rhythm of the game.

8. 8

   Final debrief and transfer to reality

   15 à 25 min

   The facilitator gathers the teams and structures the discussion around the three layers experienced: visualising, limiting, measuring. They ask: "What have you learned about your tendency to start, block, help, or finish?" Participants connect the observations from the game to their contexts: projects, maintenance, incoming requests, dependencies, queues. The facilitator concludes by formulating a testable action: a WIP limit to try, a blockage to make visible, or a lead time metric to track.

   Tip — End with a concrete and small commitment: a team experiment that can be valid from the following week is better than an overly ambitious Kanban plan.

Variants

• Short version: play only iterations 1 and 2 to focus the workshop on the impact of WIP limits and collaboration, then have a longer debrief on parallels with the field.
• Metrics-oriented version: spend more time on iteration 3 and reading the cumulative flow diagram and lead times, comparing trends between teams.
• Large group version: have several teams play in parallel, then organise a gallery of boards to visually compare work in progress, bottlenecks, and improvement strategies.
• Remote version: use a collaborative whiteboard with digital post-it notes and a shared random draw via virtual coin, card, or randomisation tool; ask one person per team to track the metrics.