Gamification is a real buzzword in the tech world at the moment. But with good reason, games make things more fun.
Meaningful process change from a retrospective
A developer in my team added a question to the Start doing arm of the starfish retrospective a few weeks ago: Is there a way we can gamify our sprints somehow?
The approach to the question was two-fold:
- How can the gamification improve the efficiency of the development team?
- Can I design it in such a way that the team will enjoy it as well as make the sprints more efficient?
The outcome of the sprint gamification was the setting up of a sprint league for the team.
Every member of the team is in the league and points are awarded for each goal they own that they complete.
Each sprint league season lasts for 10 sprints. At the end of the season the winner is the one at the top of the league. There are no play-offs.
- 100 points will be awarded to the owner of a goal that is achieved within a sprint
- An additional 50 points will be awarded to the owner of a goal that is completed in the first half of the sprint
- If someone has > 1 sprint goal and achieves all their sprint goals, they get a bonus 100 points
- For every goal that is assigned to someone that is not achieved, 50 points will be deducted from their score
- If either Agency team or Client team completes all their sprint goals, every member of their respective team get a bonus 100 points
- When someone gets to 1000 they will get a on the leaderboard
How can the gamification improve the efficiency of the team?
The gamification has had the following impact on the teams it has been applied to:
- During the sprints, the owners of the goals are more focused on getting their goals completed
- The pace of the development in the first half of the sprint increased as bonus points are awarded for completing sprint goals before the half way mark
- Team members maintain their focus even if they have achieved a few of their sprint goals in order to get the bonus points on offer for completing all the sprint goals they own
- At sprint planning sessions the team think more about the sprint goals they own because if they own a sprint goal that is not completed, their points tally suffers
- The team work together to assist each other with sprint goals for the greater good of the whole team in order that the whole team can get the bonus points for achieving all sprint goals owned by a team
- The longer term performance of each team member is easy to track as those near the top of the league are very likely to be achieving goals and those near the bottom of the league are very likely not to be achieving their goals
Can I design it in such a way that the team will enjoy it as well as make the sprints more efficient?
There is no point in making a game if people don’t enjoy playing it.
The sprint league has had the following impact on the team:
- Friendly rivalry between team members
- Something quick and tangible to track team progress that everyone can access and gauge their performance against
- A fun segment in sprint planning meetings sandwiched between the more process driven What was achieved last sprint? and What are the goals for the next sprint?
- Rewards at the end of the season given to the winner gives everyone something to aim for
Applications of the sprint league
There are multiple applications for the sprint league in an agile environment
- A single product team can use the league to make themselves more efficient and encourage friendly rivalry between team members
- An agency team and client team can have a league each so the client team can be in competition in their own league as well as comparing performance across leagues
- An agency team and client team can also be in a single league – depends how the scrum master wants to run the game
- Multiple product teams running simultaneous sprints can each have their own league and then the winners can face off against each other at the end of the season in a non-agile related activity to determine the champion of champions for the season. The champion of champions can be determined by almost anything; internal code-off, game of pool, push ups challenge…
The rules and scoring system above are what my sprint leagues currently use. At the end of the season we’ll review the rules and see if any changes need to be made. There are plenty of additional rules that could be introduced such as:
- Goals with dependencies on other goals having less of a penalty if they aren’t achieved
- A goal weighting system where fewer points are given to goals that are easier to achieve
- Points for achieving a goal starting at 100 on day one and then reducing by 10 points each sprint day so completing a goal on the last day of a two week sprint is only worth 10 points
All of the above were considered when defining the rules of the game but were omitted from the season 1 rules in order to keep the game simple.
The absolute key to the sprint league is that it is a game to facilitate efficient agile development so the team must keep it fun in order to get the best results.
I have introduced the sprint league on my two projects and the initial results are very encouraging. My teams and clients are engaging with the new process and so far the gamification is having the desired effect of meeting more sprint goals and making the team more efficient.
If you introduce the sprint league to your own team let me know how you get on, in the comments.