An Exercise in Flow: The Dice Game

This content is syndicated from LitheSpeed by Lindsay Hicks. To view the original post in full, click here.

photo by fyuryu
We do a lot of training here at LitheSpeed, and our exercises are consistently among the most popular parts of our courses. We’ve had many requests over the years from participants, coaches and other trainers to use some of these exercises when instructing teams, and since we’ve garnered many of them from the community ourselves, we tend to readily accede.

Here is one simple but powerful exercise that can be used to demonstrate several aspects of flow, value and teamwork: The Dice Game.

Materials: Obtain 10-15 multisided dice per group of 5-7 people. Transparent dice and ones with un-inked numbers can help make the exercise more challenging (and realistic). You can get these at any store that specializes in board games.

Setup: We are building an application, and each die represents one feature (or User Story) that our customer values. We’ll compare several different ways to perform this work, including a waterfall delivery method, continuous flow/Kanban, and Scrum.

Time limit: 2 minutes per round


  • ScrumMaster: Ensure rules are followed, add up points
  • Product Owner: Accept delivery to confirm receipt of points
  • Team: Each person on the team will turn the dice in a certain way to represent a specialized activity, such as analysis, design, development and testing.
Define an activity for each participant except for the ScrumMaster and Product Owner. For instance:
  • Analysis would be performed by turning a die and placing it on the table such that the number 1 is facing up.
  • Design would be performed by turning a die and placing it on the table such that the number 2 is facing up.
  • Development would be performed by turning a die and placing it on the table such that the number 3 is facing up.
  • And so on, ending with the Product Owner, who turns the dice one more time to accept them.

Feature Scoring: Teams get 1 point for every die that has been completed (proceeded through all of the defined activities by turning the dice through each number). For instance, if you defined five activities (e.g. Analysis, Design, Development, Testing, Deployment), the die would have to be turned to 1, then 2, 3, 4 and 5 sequentially; when it reaches 5, it is Done and gets the point.

You can also choose to give more points by die complexity (e.g. 1 point for 4-6 sides, 2 points for 7-9 sides, 3 points for anything more complex). This makes the Product Owner role more meaningful and challenging.

Release Scoring: 10 points for every complete set of one die shape (e.g. all of the cubes, or all of the tetrahedrons). You can also use similarly colored dice to represent Releases.

Delivery Method Variations: Each team or table can represent a different method of delivery. We usually have everyone do this in parallel, working within the same two-minute timebox, and then we compare results at the end. Common variations include:

  • Waterfall – Every person represents a different specialty (e.g. analysis, development, testing). Each person must flip every die before the next person may begin.
  • Continuous Flow/Kanban – Every person represents a different specialty as above, but only has to flip one die before passing it along, resulting in a steady flow of value. If multiple rounds are performed, teams can look for bottlenecks (where a few dice pile up consistently in front of someone) and adjust the amount of dice allowed to be in one’s “outbox” as needed to reduce these bottlenecks. For instance, the person representing Design may be able to place 2 dice in Development’s queue, but no more, while Development may be allowed to place 3 dice in Testing’s queue.
  • Scrum – The same activities must be performed to deliver a feature as above (e.g. turning each die through each defined number), but here teams are asked to design their own process, choosing how to address the “backlog” of dice and who will do what. It is allowed for a single person to flip a die through every stage, if desired; here, the metaphor would be that this person represents a cross-functional team by themselves. This variation works best across a few rounds, as teams can then inspect and adapt.

Debrief: Several learning points tend to surface during this exercise. The instructor can ask each group many different questions to help cement these points, such as:

    1. Did you feel like a team? (typically, Waterfall group: no, Kanban group: sort of, Scrum team: yes)
    2. What would happen if something happened to kill the project 75% of the way through? (Waterfall: disaster, Kanban & Scrum: we would already have the presumably highest value features built at that point)
    3. [For Kanban team] Did you see any bottlenecks forming? How would you deal with them? (people should help those performing downstream activities, requiring some skill overlap and sharing)
    4. [For Scrum team] Did you change your process midstream at all? How would you change things next time to be even better? Did you encounter any dice that could not be processed? (e.g. if you have tetrahedrons, but there are 5 or 6 steps total, they will be impossible to finish, representing a technically infeasible feature; most people won’t realize this until already well underway, demonstrating that actually doing something is a quick way to learn about how to do it properly, whereas vacuum-chamber analysis often misses such things initially)

Key Learning Points:

  • Value is delivered more rapidly in small batches
  • Steady delivery of features mitigates the risk of non-delivery
  • Small batches reduce the impact of customer changes (you can demonstrate this by changing the activities or scoring mid-round at some point)
  • Teamwork is more prevalent when activities are shared and when there is frequent interaction
  • New skills can be built over time by frequent interaction between those performing neighboring activities, leading to more polyskilled team members and hence more fruitful collaboration
  • Work in small batches is less complex (e.g. flipping one die is easy, but it’s harder to keep track of the state of 15 dice at once)
  • Optimal release strategies can maximize the flow of value, hence the necessity of the Product Owner role
That’s it! We hope you find this useful in educating your teams, and if you have any great exercises that you’ve used yourself, we would be thrilled to hear about them. Until next time…

Leave a Reply

Your email address will not be published. Required fields are marked *

3 × 1 =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”



To explore how we can help you, please get in touch