Rocket to Mars: A Sprint Planning Game
“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”.
Too much attention to velocity or Story Points
Thanks for the article but more and more I believe that people forget the most important thing in sw development: "VALUE".
Does not matter if you deliver 100 stories or 1000 story points, what matters is the value that you give to your customers.
What is more important:
a) Team that delivers 20 story points and bring zero euros revenue
b) Team that delivers 5 story points and brings thousands euros revenue
I think we should focus more in figuring out the value that we are delivering instead of trying to improve velocity!
Re: Too much attention to velocity or Story Points
Of course you're right. Value is paramount to the agile movement : focus on delivering working software not executing the plan.
However, too often, this command is taken with a short term view that kills agility: "delivering value" becomes delivering more and more features, faster and faster.
In this game, we wanted to help the team and their managers realize that delivering value in the long run requires diverting some of your time on other activities like technical debt reduction, knowledge growth, team building, ... and so on.
Of course this is a game, designed as a learning tool. It does mimic some aspects of reality but it isn't real.
For the sake of the gameplay we chose to make the simplification "value // effort".
There are games (like the XP Game) where the players need to make the correct balance of value vs effort but here we wanted to offer clear alternatives (and thus a clear learnings): with given priorities, should we produced more or rather prevent risks, should we go for quick wins or long return on investment ?
Apparently the game works since players, who where almost all experimented Scrum masters or Scrum practionners, told us it had helped them realize that they did not always make conscious choices about these alternatives.
That was our goal: tell them to surface these questions and discuss it with their PO and team at the sprint planning.
Re: Too much attention to velocity or Story Points
I see too many people worried in velocity and speed but not even thinking about value :).
In any case the game looks nice, congratulations.
Not yet but I'm working on it :-)
I'll post a comment here when it is available.
Mike Hartington Jul 26, 2015