Scrum — The Collaborative Board Game

Presented as Open Space session April 11, 2018 at Agile Games 2018 in Boston for fun and feedback by David Koontz.  

With a 50 min. session, and a small group of 6 participants, I tried to speed up the learning cycle by guiding the group thru the setup and learning of the game, rather than having them read/understand and comprehend the instruction.  In the introduction I believe I made the point that the game was intended to allow participants to experience the synergies of various options that happen while doing scrum, yet not to teach the basics of the Scrum process.

I handed out the instruction sheets and quite a few questions came up referring to the instructions, so people did read and use the written instruction (specifically the PO).  To jump start the group with Simulated Sprint Planning, I asked the PO to choose 3 high value/low effort stories for the first sprint. And to quickly move to action I created a sticky with (item label, dollar value, effort size) and place it on the game board for each of the PO’s 3 stories.  Then explain the game rule that a story has a task for each effort point I stuck task stickies to the board.  And then the team was instructed to roll the die (1 -3) to determine (by chance) the number of days it would require for each task.  These numbers were written on each task sticky.  We declared Sprint Planning done and started the first Daily Scrum.  In the daily scrum we decide which team members would work on which Stories/tasks, moved the daily marker on the board, and then each (all) team members working on a task drew a HappenChance card, performed the work (as instructed via the card) moved task to in process, marked tasks with remaining work required, and chatted about the results of the happen chance.  After day one, the group had the general understanding of the game’s mechanics and were sprinting.

There were a few questions that came up… and typically someone had read the instructions and could point to the game rules to answer the question.  A few times this was vague and I just made up a reasonable answer… and we kept playing (or created a feedback item for Tim & Derek).  It was nice to have a few observers (not everyone in the session was playing the game) these people offered perspective and alternative ideas – as well as correcting the facilitator’s misuse of common Scrumy terms (e.g. saying Sprint Planning instead of Daily Scrum).

The general feel for the open space session was positive, I believe people enjoyed the game,  perhaps the biggest challenge I heard was in discovering the purpose and intent of the game.  I attempted to elude to this while leaving open the possibility of discovery.  Perhaps that was a slight mistake on my part.  However, upon reflecting, I believe the game achieves it’s purpose.  I can tell from the suggestions.  The feedback is to add other options to the game play, such as automated testing to reduce defects, to add variety and originality to the game.

The affinity grouping of written feedback (and slight editing for context):

Some mechanism to note which Task corresponds to which Product Backlog Item.

Shorter text on happenchance cards

Place on board for completed sprint backlog items

Multiplier on Tech Debt

Consider carefully the probability of getting more new problems & tech debt than work done

Don’t have two pieces of the same character in different colors (e.g.  pink elephant & purple elephant)

Encourage active engagement from PO – e.g. HappenChance cards that engage the PO

More scenarios of HappenChance cards, too much repetition.

Show value of Scrum Master – Have a role, removing impediments and actions tied to burndown chart – which encourages swarming

It might help if the backlog were magnetic and could be moved around

Helpful to have chips or coins to mark items as done

If you (PO) split a story with high value it is hard to get back to that value (given rules & dice 1-3 points).  It encourage one to split a low value task.

More variety in wording identical happenChance cards

Ways to involve the PO more

Is all Tech Debt discovered?  Or does the team create some?  Does Pair Programming reduce creations of Tech Debt?

Does a practice such as Automated Testing reduce effect of defects?  Is this an aspect of SW Dev that could be added to the Game?

I’m curious how gameplay copes with pace with a full team playing?

Is there a mechanic to scale impact of Tech Debt & Defects as they mount up?

Simulation looks great on practical level.  

Enjoyed the concepts