Blog

Scrum basics using fun games

14 May, 2008
Xebia Background Header Wave

For a training on Scrum and Agile I was planning to give I was looking for games to play during the course to explain some basic things. Ofcourse we would be playing the XP game but I wanted something more to explain some other fundamentals.

One of the games I found interesting during my own trainings was Goldratt’s dice game. For the training I was preparing an adjusted version of Goldratt’s dice game. As you might know Goldratt’s dice game illustrates the effects on variation in processes and its effects on cycle time. You can find a simulation of it at https://www.ganesha.org/leading/toc.html.

Next to that I wanted to have another game to illustrate the effects of having large inventory and the difference between push and pull production. After a few minutes searching the web I found the CUPS game. (https://web.lemoyne.edu/~wright/cups.htm).

The Cups game is about the difference between push and pull production. It helps you illustrate its effects on inventory, costs, rework and ability to respond to change. One of the main things of being Agile is of course your ability to react to change and generate feedback, see https://cesarioramos.wordpress.com/2008/03/23/improper-feedback/.

I found that the outcomes of these games are easily related back to Lean and Scrum principles and that they can be used to have some fun and easily explain things during training.

How does Scrum relate to Goldratt’s dice game?
Using Goldratt’s game you illustrate that in order to maximize throughput you should minimize variation in processes. Scrum helps you achieve this by minimizing disruptions of work and achieving a sustainable pace throughout the project!. See also https://jeffsutherland.com/scrum/2007/07/origins-of-scrum.html

How does Scrum relate to the CUPS game?
The CUPS game helps you illustrate that we should limit work to capacity and keep inventory low if we want to be agile and effective. If not, your cycle time will go up and as a result your agility down! Scrum offers a way to limit work to capacity through its sprint planning. We know that during sprint planning the amount of selected work should be based on the team’s capacity.

There is also Little’s Law stating that WorkInProgress (WIP) = CycleTime (CT) * ThroughPut (TP). So to be able to respond quickly to change you should minimize the CT. We know that one way to achieve that is to minimize WIP. For a Scrum project you could say that the WIP is equal to the Sprint Backlog and the number of Product Backlog stories that are worked out in detail. So what is the minimum WIP that you should use? Again Scrum has some simple principles to help out. One of them being that we should focus on the top product backlog user stories the next sprint. So working on these and detailing them before the next sprint planning takes place is a good idea. How much work should be detailed? well… at least the team’s current capacity! I prefer to use the plan, do, check, adapt cycle. So I would first see how it goes with a WIP of about 2 times (sprint backlog and detailed stories on the product backlog) the team’s capacity and then take it from there.

If you want to have some extra fun during the CUPS game you could do so by changing requirements during the process.

Have fun!

Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts