Business Simulations / Business Simulations

Agile Product Management — Workshop with Building Bricks

A one-day agile product management workshop run on building bricks. Teams build a city for a demanding client in short cycles: plan, build, present, revise. Backlog, Kanban board, user stories and the Product Owner role are practised on a physical product rather than on slides.

A project that fits on one table

The hardest thing about learning to work in an agile way is the delay. Results show up months later, by which point nobody remembers which decision produced which consequence. This workshop compresses that loop into tens of minutes. A team takes a brief from a demanding client and builds them a city out of bricks, one cycle at a time: plan, build, present, revise.

Every round exposes what it costs to hold on to a plan that has gone stale, and what fast feedback is worth. By the second cycle the room usually arrives at the same conclusion on its own: the winning team is not the one that planned the most, it is the one that learns the fastest.

Who it is for

Teams where plenty is happening but progress is hard to demonstrate. Leaders whose priorities change faster than they can be agreed. Organisations that want to stop over-planning but are not sure what to put in its place.

The workshop assumes no preparation. People with no agile background learn the fundamentals by doing them; people already working this way most often take away something else entirely — a chance to watch their own team habits play out on neutral material.

How it works

Participants work in teams of four to six. They build a backlog, write requirements as user stories told from the residents’ point of view, run a task board, and close each cycle with a working part of the city.

Nothing is taught up front. Concepts arrive at the moment a team hits the problem that concept answers — Definition of Done when it turns out “finished” means something different to everyone at the table; limiting work in progress when five buildings are half-built and none is done.

Why bricks rather than a paper exercise

Because the product has to be visible. With bricks you cannot hide that something is half-finished, that two teams built the same thing, or that the bridge does not meet the road. What takes weeks to surface in a real project shows up on the table immediately, and without a status report.

We run this workshop on site only. The shared table, where everyone can see everyone else’s work, is a working part of the method rather than a nice touch.

Benefits

Build a backlog and keep it in meaningful priority order throughout a project
Express requirements as user stories written from the recipient's perspective
Plan a short cycle and close it with something that works, not a progress report
Run a Kanban board so that it limits work in progress instead of disguising it
Recognise the moment when sticking to the plan costs more than changing it
Hold a scope conversation with a decision-maker when time is running out
Use retrospectives as a mechanism for change rather than a reporting ritual

Who is this training for?

Project teams where a great deal is happening but progress is hard to show

Team leaders and managers looking for a simpler way to run the work

Teams working with a client for whom changing requirements are routine

Organisations moving away from heavy planning towards measurable outcomes

Cross-functional teams whose priorities shift frequently

People starting out with agile ways of working, with no prior Scrum exposure

Teams where decisions get postponed or dissolve between people

Prerequisites

No prior experience with Scrum or agile methods is required
Experience of working in a team or on projects, in any role
Willingness to work hands-on at a table and present results to the group

Training program

Framing: the city as a metaphor for a product — what value means to the person receiving it
Splitting into teams of four to six and assigning roles, including Product Owner
Building a backlog from what the client says they want
Writing requirements as user stories, from the point of view of the city's residents
First cycle: planning, building against the clock, presenting the result

The client reviews the work — assumptions meet expectations
The Kanban board: making progress visible and exposing work in progress
Reordering the backlog when the brief changes mid-project
Definition of Done — when a building is genuinely finished
First retrospective: what the team will do differently next cycle

Second and third cycles — putting the retrospective decisions into practice
The tension between time, scope and expectations, and how to talk about it
Why the fastest-learning team wins rather than the one that planned the most
Comparing results across cycles and drawing team-level conclusions
Carrying the workshop mechanics back into participants' own projects

Delivery Methods

On-site

Direct contact with trainer and group
Intensive hands-on workshops
Networking with other participants
Full focus on learning

Training Topics

The backlog and how to keep it ordered User stories as a way of capturing a requirement The Product Owner role and product vision Planning a short cycle of work The Kanban board and limiting work in progress Definition of Done and the quality of the result Prioritisation under changing requirements Client feedback as a steering mechanism Retrospectives and team learning The tension between scope, time and expectations Iterative work versus planning up front Transferring workshop experience into real projects

Frequently asked questions

Do participants need to know Scrum beforehand?

No. The workshop introduces each concept only once the team has run into the problem that concept solves. People with no background pick up the fundamentals by doing; people already working in an agile setting usually take away something different — the chance to see their own habits from the outside.

How many people can take part?

Between 5 and 30. We work in teams of four to six — a smaller group forms a single team and the dynamic changes, while a larger group adds further teams building districts of the same city.

Can the workshop be run remotely?

No. The point of the workshop is working with your hands on physical bricks at a shared table where everyone can see everyone else's work. We do not run a remote version — for distributed teams we suggest one of our simulations that is designed for remote delivery.

How does this differ from a certified Scrum course?

A certification course prepares people for an exam and organises their knowledge of the framework. This workshop prepares nobody for an exam — it delivers several complete work cycles in a single day, which in a real project would take weeks. It works well as a lead-in before a certification course, or as a way of grounding one afterwards.

Do we need to supply any materials?

No. EITT supplies the bricks, workshop materials and everything else. You need a room with large tables — one per team — and a wall or flipchart for the task board.

Is a certificate issued?

Yes, every participant receives a personalised certificate of completion issued by EITT.