Agile – Sprint Goal Ownership

Retrospectives improve process

Far too often retrospectives become a chore that agile teams feel obliged to do and forget their core objective of being an open forum for the team discuss both triumphs and failures in order to improve processes and efficiency. Happily the team I work with use our retrospectives for their intended purpose and there have been some significant changes in the way we do things that have made the whole team work more efficiently and produce better outcomes.

The poor PM

Before the change in process, the team were setting goals every sprint. The problem came at the sprint planning sessions where we reviewed the previous sprint and saw that we weren’t achieving all our goals. In some sprints we were only achieving 1/3 of our goals.

The obvious conclusion to draw from these failures is that we were setting too many goals. Upon inspection of our sprint velocity compared with the amount of development time in the sprint, the amount of goals looked to be accurate. The conclusion we drew therefore was that there was a lack of focus in our team when it came to completing goals.

One of the main issues we face in our team is that there aren’t separate roles for scrum master and product owner. These roles end up being performed by a single person, the project manager (PM). When these roles are combined, the PM’s focus is split between tracking the current sprint, grooming future sprints and scoping out future features.

Goal owners

Our retrospective had the following outcome. Where previously we had multiple goals and a single role (PM) assigned to completing the goals, we now have multiple goal owners.

We found the benefits of this change in approach were threefold:

  • responsibility for completing goals now rests with multiple owners instead of one
  • there is a greater sense of the team working together to complete goals rather than relying on one individual to drive all goals toward their completion
  • the PM has more time to focus on grooming future sprints and scoping out features in more detail

The result

The introduction of this change in process saw an immediate impact on sprint goal completion and team efficiency and is now a core part of our planning and execution.

Agile Gamification – Sprint Leagues


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?

Sprint League

The approach to the question was two-fold:

  1. How can the gamification improve the efficiency of the development team?
  2. 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 (star) on the leaderboard

Agile team

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:

  1. During the sprints, the owners of the goals are more focused on getting their goals completed
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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:

  1. Friendly rivalry between team members
  2. Something quick and tangible to track team progress that everyone can access and gauge their performance against
  3. 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?
  4. 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.