Collaborative Games · Business Analysis Notes

What it is#

The BABOK® Guide describes collaborative games as techniques inspired by game play that encourage people to work together on a shared goal. Each game has rules, a goal and a defined time, and a neutral facilitator guides the group through three stages:

Opening: participants learn the rules, the goal and the limits, and start generating material (ideas, notes, sketches).
Exploration: participants work with the material: they connect, compare, test and build on it. This is where new insights appear.
Closing: the group converges on conclusions, decides what matters most, and records outcomes and next steps.

The BABOK Guide gives three examples:

Product Box: small teams design the packaging for the product or solution: a name, the key features on the front, a slogan, and details on the back. Teams then “sell” their box to the others. It reveals which features people consider most valuable and how they would describe the product to buyers.
Affinity Map: participants write items (features, problems, ideas) on notes, then group similar items together, often in silence, and name each group. It reveals patterns and categories the group had not stated.
Fishbowl: the group splits into an inner circle that discusses a topic and an outer circle that only listens and takes notes, then roles are discussed or swapped. It brings out hidden assumptions and helps one group truly hear another.

Facilitators use many other games that follow the same three-stage structure, for example games where participants mark what pushes a project forward and what holds it back.

When to use it#

When stakeholders seem to agree in words but may mean different things.
When you suspect unstated assumptions about a problem, a product or a group of users.
When some participants rarely speak in normal meetings.
When a group needs fresh thinking or energy, for example at the start of a long workshop.

When not to use it, or what to add: the BABOK Guide notes that games can seem frivolous to participants, especially senior or very task-focused ones, can take more time than expected, and can give the group false confidence in conclusions reached in a playful setting. Avoid them when the audience will not accept the format, or when you need precise, detailed information; use Interviews or Document Analysis instead. Always confirm game outcomes through another technique before treating them as requirements.

How to do it#

Define the purpose. Write the one question the game should help answer, and what you will do with the result.
Choose the game that fits: Product Box for value and priorities, Affinity Map for structuring many items, Fishbowl for hearing a group’s assumptions.
Choose participants. Mix perspectives; for a fishbowl, decide who sits inside first.
Prepare materials and space: boxes or cards, sticky notes, markers, wall space, a timer; or the equivalent online board.
Run the opening. Explain the goal, rules and timing in plain terms. Frame the game as a working method, not entertainment.
Run the exploration. Keep time, keep energy up, make sure everyone contributes, and note recurring themes and surprises.
Run the closing. Ask what the group learned, which assumptions surfaced, and what should happen next. Capture results with photos and a written summary.
Follow up. Send the summary, log open questions, and plan how to confirm the findings with other techniques.

Example#

At The Workshop (a fictional chain of 12 bike-repair shops), the analyst wants to know what customers and staff value in a booking and status service.

Product Box with three mixed teams (managers, mechanics, front-desk staff and three invited regular customers). Two of three boxes put “know when your bike is ready” on the front; only one mentions online booking at all. Insight: transparency matters more to customers than booking convenience.
Fishbowl with front-desk staff in the inner circle discussing “what happens when a customer calls about a repair”, while the developers listen. The developers learn that most status calls are about delays waiting for parts, which nobody had mentioned in earlier interviews.
Closing: the group agrees two candidate priorities, and the analyst plans to validate them with a short customer survey.

Common mistakes#

No clear purpose → state the question first; without it the game feels frivolous.
Skipping the closing → reserve time to converge and record outcomes; that is where value is captured.
Treating results as validated → confirm findings through other techniques before acting.
Wrong audience → check that participants will accept the format; adjust the framing or choose another technique.
Facilitator takes part in the content → stay neutral and focus on the process.
Running too long → time-box each stage and stop while energy is still high.

Checklist#

The question the game should answer is written down.
The game fits the question and the audience.
Participants represent the needed perspectives.
Materials, space and timing are prepared.
Opening, exploration and closing each have time reserved.
Surfaced assumptions and conclusions are recorded.
A plan exists to confirm the findings.

Sources and further reading#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Technique 10.10 “Collaborative Games”.