The Ball Point Game Variations

Recently I’ve written a post about The Ball Point Game, a game that simulates Scrum with all the sprint ceremonies, such as planning, sprint, review and retrospective. Here is an addition to that post which offers interesting variations to the game.

Set an additional hurdle

Additionally to the game’s rules (which are constraints), you could introduce one more hurdle in order to demonstrate which effect it might have (positive or negative). For example each ball has to pass through small piece of pipe in addition to the existing rules (which reflects an unnecessary process that slows the team down).

Request a stretch

Under normal circumstances there will be improvements from iteration one to iteration 3. Then teams often feel they can do much better. That’s the time to ask them for a stretch in telling “I’ve seen other teams achieving ver 200 points” (choose a number that reflects a realistic stretch to the teams output). The main goal of this input is to get the team not limiting itself by thinking of their past achievements. In most cases teams perform better after introducing the stretch.

Playing the game with balls of different sizes

Balls of different size representing backlog items of different sizes show the impact of product owner work and backlog quality. The team usually struggles more with balls of different size (which represents backlog items of different granularity and different levels of uncertainty). That learning for the team and the product owner is the importance a good refined product backlog, in order to maximize the value that the team achieves per iteration. In real life situations the “Definition of Ready” is a great tool to support you. I’ve published posts about the subject of ready user stories and good product backlogs for further reading.
A good question to ask after the game, is: What impact did the size of the balls have on the teams performance?

Introduce a Manager to the game

Another variation is to introduce one (ever even more) manager to the game. the role of the manager is to act outside of Scrum rules and just pass balls into the team that bypass the product owner. This simulates the impact of not planned work and undermining the product owners responsibility.
When introducing a manager, do this in the first iteration in order to see improvements in later iterations. As the Scrum Master is a servant leader to the team, you should also help the team and stop the manager if they ask for it (which might happen in the retrospective after the iteration).
A good question to ask after the game would be: What impact did pushing balls during an iteration had on the team and the outcome? If they didn’t ask for Scrum Master support, you may ask the team for the reason.