This is a game I created, which was then used and refined by me and my colleague Laurie Young to help gauge how well everyone involved in a project understand their responsibilites to the project and each other. It lends insight in to the pre-conceptions that people have about how projects should be run, which helps you tackle potential problems early.
It has really helped projects get off to a good start and its good to revisit later on to see how peoples understanding have changed.
Timings: 1hour – 1hour 30mins
Materials: The Team, White Board, Pre-written out index cards, Blank index cards, Pen, some method of sticking cards up (magnets, bluetac etc)
Instructions: Draw a big circle on the whiteboard, inside that draw a smaller but reasonably sized circle in the middle. You should now have something that resembles a ring doughnut. Now draw three equidistant lines from the outer circle to the inner circle as if you are going to divide said doughnut equally between three people.
In the very centre of the doughnut write “Everybody” and then put one of the following in each section of the doughnut: Product Owner (PO), Development Team (DT) and Scrum Master (SM). Finally on somewhere outside the doughnut write “no one”.
Now on the index cards write roles and responsibilities with in the Scrum Framework. These are some of the things I have written down in the past, but its certainly not the exhaustive list:
- Scope
- Cancelling a Sprint
- Changing the Product Scope
- Conveying The Product Vision
- Prioritises Product Backlog
- Prioritises Sprint Backlog
- Writes User Stories
- Facilitates Meetings
- Facilitates Retrospectives
- Builds the Product Backlog
- Commits to a Sprint Backlog
- Remove Impediments
- Motivates the team
- Protects the team from outside distraction
- Chooses the Amount of Work in a Sprint
- Commits to Completing the Sprint
- Inspects and Adapts to Improve their Performance
- Manages the Team
- Points Out Other People’s Mistakes
- Makes Sure the Product Works
- Accepts a Story as Ready
- Recognises Impediments
- Accepts a Story as ‘Done Done’
- Ensures Something Useful is Built by Launch Date
- Represents the Business/Customers
- Keeps Stakeholders Informed
Now get everyone in the team to arrange the cards on the board. If a responsibility is for one section of the team it lives in its specific area of the doughnut. If two groups share it, it goes on the dividing line between them and “everyone” and “no one” are self-explanatory.
The way that has worked best for me is tackling each card at a time, talking about it and trying to reach a consensus on where the card belongs, but you can equally get all the cards up there and start pulling them off. I find that can get confusing though.
Variations: This can be used for developing broad understanding of Scrum, but also for specific areas that we may be misunderstanding i.e what are our responsibilities for testing?. I also find that asking: “Where do you think this card goes?” reaps different result to asking the question: “Where do you want the card to go?” so I am sure there are other clever questions that can be asked while playing this.
Learnings:
- This is a very good game for setting the expectations within the team and avoiding conflict due to misunderstandings.
- It establishes a level of good communication throughout the team.
- Creates a very focused discussion on what things should be happening on the project overall.
- Can create commitments from everyone early on.
- Helps expose misunderstands that have grown over time.
- Reinforces the idea of the whole team being the committed people on the project (if you are bored of pigs and chickens).
- It helps highlight responsibilities that no one has taken on or thought about.
Still using this game, even more so during COVID!
Mural version: https://kitfriendesq.medium.com/
Still loving this game years later – here’s a Mural templated version: https://app.mural.co/template/76cafd9c-0f1a-4b64-983b-8132763544d9/5761c826-ad1f-4334-8d1e-91d59ef2a385
Use this all the time 🙂
Just about to pilot a Google Drawing-based version for some online training soon: https://docs.google.com/drawings/d/1rjB8FFoUHZ0d2kuHJorAZoINWSjiEB6Ss4BK2IAYuf4/edit?usp=sharing
i LOVE this game and play it with ALL new teams after i have reviewed the scrum framework – this is part of the Review we do on day 2 of team training. Thank you so much Sam!
Thanks for the initial work, Sam! Like so many others, we have found it useful, mainly as a discussion starter. I changed it to “SCRUM-ptious” Donut Game (Herculean fits, as it is very large, but I couldn’t resist the word play.) We added a few others, and changed some of the wording. And to echo what many have said, it’s more about the journey; not about getting it right immediately. Our experience helping teach has been distinguishing between the “book” answer for some and our own real world examples. And we bring in donuts to get started, which is always a big hit.
Sam, this is a great game. It definitely promotes team collaboration, and allows everyone to participate and have fun at the same time. But, I work a lot with distributed teams, it’s unfortunate, distributed teams don’t seem to have a fair shot at this game.
Been using this actively for a while now. Great game that drives some very interesting conversations. I added to the list of activities/responsibilities and threw in some others such as dealing with budget, risk, performance management, motivation, creating status reports, and other things I seem to remember from my project management past (its alright I’m better now!) etc. – As Bethhold said this is so much more about the the journey. Its the conversation that is really important. Nice one Sam – thanks.
As with the Planning Poker Game, the journey is the goal here. On top of helping a team make sense of the roles that Scrum offers, the discussions led to a deeper insight into the reasons for the division and left room for discussing ambiguities past and future. Plus it gets the team off their butts.
Thanks for the comments.
It is, on a visual level, just a less confusing Venn Diagram (shhh don’t tell anyone), however it also emphasises that you can leave things outside for “no one” to do.
Ultimately, it’s as much a chance for the team to make mistakes they can then learn from as it is about getting it right first time. In my opinion some responsibilities are are not always either prescriptive or obvious to the roles as others. If a PO happens to be a brilliant motivator of people, then seems a shame to waste that natural ability and I think that increases the likelihood that the team will include him in that responsibility. The one benefit I have always got from this is that when finished, whether its what the text book says or not, everyone leaves having accepted responsibilities.
I am really glad you found it useful.
I use a similar game, though with a Venn diagram instead of a doughnut. This leaves some nice room for discussion as to whether everyone should be responsible for a given role, or whether only two people should. E.g. from your above examples I’d argue that “Motivation of the team” should come from the SM and the Team, but probably not the PO.
I’m sure there are people out there who’d disagree however….
I found this exercise very worthwhile and provoked great conversation among teams I’m working with transitioning from traditional roles to that inside of a Scrum Framework.
Adding to the variations, we had our traditional roles on a separate board with duplicate cards so they wouldn’t have to remove them from the doughnut. There we asked them to place them according to current/past responsibilities. This was just an enlightening lesson due to that the scrum doughnut for the most part will look the same, however, the traditional board VARIED so much among the groups we went through this exercise with. Some had 70% of the stuff on the project manager, some had a majority of the items on the BA with very little if any on the business partners/SME.