BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Rocket to Mars: A Sprint Planning Game

Rocket to Mars: A Sprint Planning Game

This item in japanese

Lire ce contenu en français

Bookmarks

“Many team and their product owners believe that the team's unique job is to deliver more and more story points, but we consider this to be a complete misunderstanding of the relation between the team and the product owner” said Damien Thouvenin and Pierrick Revol. At the XP Days Benelux 2013 conference, Damien and Pierrick facilitated a sprint planning game for teams and product owners to learn about deciding to invest their sprint time to produce stories, investigate issues, reduce technical debt, or do training. 

Rocket to Mars (v2) is a collaborative role playing game for Scrum product owners and teams and their managers to learn agile and lean planning practices. It is a board game played by teams who choose and adapt their strategy to build a rocket for the next mission to Mars. In the game they take decisions to do in-depth analysis or to start coding, develop expertise or generalist skills, and to refactor or finish user stories to burn down more story points. The aim of the game is to score the most points in 8 iterations, where team score points by finishing user stories but points are deducted when they have accumulated technical debt. The game is a successor of the Mission to Mars game.

Initially team members are only skilled to do one activity, by doing training they can develop new skills. When team members have these skills they are able to do different activities and the team will become more multidisciplined and capable to do more work in an iteration.

This game is influenced by a talk by Prof Philippe Kruchten, covered on InfoQ in what color is your backlog, where he talks about key decisions that need to be made early that will set the scene for ongoing work. This talk explains that every sprint the team has to decide if they will work on delivering new functionality, solving bugs, or invest time in training. Damien and Pierrick showed how these decisions fall into 4 quadrants covering short-term vs. long-term effects (or visible and invisible effects) and producing up vs. preventing risks:

Damian and Pierrick asked the teams what they have learned from playing the game. One team explained how they were hampered by illness, which caused their velocity to go down. There was not much that they felt that they could do to address that. Another team explained how investing early in training helped them to become faster in the next sprints. Other feedback received was that playing the game “showed the true value on investing in training and analysis”, “the game show the real life issues during sprints”, “gives a good view on the difference between sprint backlog and product backlog at sprint planning”, and “the game is a lot of fun, learned a lot”.  

During the debriefing Damien explained how a strategy can look to deal with functionality, technical debt and training in the planning game:

What people learn through the game is that the sprint planning should not be concerned only with how many user stories we can stack in the sprint backlog. The concern of the team and the PO should be to enable long running sustainability. Since there are no "inter-sprint" spaces, that means all those activities must take place during the sprint: reducing technical debt before it explodes and blocks you, investigating future stories or epics, grooming you backlog, exploring technical options for the next sprints, training people on technical or business subjects.

The conclusion from playing the game, as Damien stated, is that “the team and their product owners should have discussions about how they want the team to invest her sprint time: producing story points, investigating the next issues, killing debt, or do training”.

Rate this Article

Adoption
Style

BT