Getting to Done: Creating Good Sprint Goals

In a previous post describing challenges to creating a done Increment, I identified a lack of clear Sprint Goals as one of those challenges. According to the Scrum Guide, the Sprint Goal is an objective to be met by the Sprint through the implementation of part of the Product Backlog.

The Sprint Goal provides guidance to why we are building the Increment.

If we have a Sprint Backlog, essentially the plan for the Sprint, why do we need a Sprint Goal?

Remember that software development is complex, and we cannot plan perfectly for the unknown.  When we create the Sprint Backlog, there is an expectation that work will emerge during the Sprint.  Scope may need to be re-negotiated.  The Sprint Goal helps provide focus on an objective we want to achieve and allows the flexibility to negotiate the work to achieve that objective.

Creating a clear Sprint Goal can be challenging for Scrum Teams, and this often comes up when I teach Professional Scrum courses.
4 Challenges With Sprint Goals

(and some tips for resolving them)

When we have compound Sprint Goals (e.g. achieve X and Y and Z), we are splitting focus and not allowing much flexibility.  Here are a few reasons we end up in this situation and suggestions for how to think differently.

• We are working on multiple unrelated projects or initiatives.  When we are ordering the Product Backlog and doing Sprint Planning, consider both cohesion of the work and the top priority initiative.  When we cram too much into a Sprint, we are setting ourselves up for failure.  We end up with waste due to context switching and little room for the work to emerge as we learn.  If it feels impossible to choose one, perhaps our Sprints are too long and do not provide the business the opportunity to change focus and direction frequently enough.


• We try to encompass every Product Backlog Item (PBI).  When I teach Scrum courses, I often hear that teams consider their Sprint Goal to be "complete every PBI."  This is the equivalent of not having a Sprint Goal at all.  This feels a bit lazy.  Yes, coming up with good Sprint Goals is hard.  Take the time to do it.


• We think the team may not work as hard if the challenge isn't big enough.  This sentiment reminds me a command-and-control mindset.  If self-organizing, empowered teams are to be effective, we must believe that people are committed to doing their best.  If the Sprint Goal is met before the end of the Sprint, professionals will figure out what else they can do to contribute in meaningful ways.  This could mean delivering more functionality.  This could mean working on continuous improvement items.  Trust them to figure it out.

When we get to the end of a Sprint, is the entire team in agreement on whether or not the Sprint Goal has been achieved?  If not, the Sprint Goal may be too vague.  Here are a few tips for creating more clear Sprint Goals.

• During Sprint Planning, ask "how will we know if we have achieved the Sprint Goal?"  If we have different answers or puzzled looks from the Product Owner or any Development Team members, then we need further discussion and refinement of the Sprint Goal.


• Make the Sprint Goal measurable.  This helps reduce subjectivity, or opinion.


• During Sprint Planning, use a consensus technique to confirm everyone's understanding and commitment to the Sprint Goal.  This is also a way to help encourage team ownership.

Here are some examples of unclear Sprint Goals and modifications to make them clearer.



Unclear Sprint Goal
Clearer Sprint Goal


Enhance shopping cart functionality.
Streamline purchasing process to enable an increase in conversion rates.


Improve performance.
Increase page load time by X%.


On-board new market segment.
Enable new market segment to purchase Service Y.




Remember we have to actually pay attention to it to help provide focus.

• Make it visible.  Write the Sprint Goal on or near the Scrum Board.  Make it large.  Use a color or border that stands out.


• Teach the team to talk about progress towards the Sprint Goal in the Daily Scrum.  Development Team members often give updates about the Product Backlog Items they are working on, and the Sprint Goal is never discussed.  Make it part of the Daily Scrum.


• Make the Sprint Goal a team measure and keep it visible in the team space.  Similar to how a team may track their velocity or automated test coverage over time, a team can also track Sprint Goal achievement over time.  Keeping this information visible helps the team think about it.  Historical data and trends can be used for discussion in the Sprint Retrospective.  A word of caution:  achieving a Sprint Goal is pass/ fail.  There is no such thing as 85% achieved.

A Sprint Goal is supposed to provide purpose.  It helps the team know why they are building the Increment.  People want to do meaningful work.  People want to do work that has an impact.  This is a driver for intrinsic motivation.  Lets think about ways to make Sprint Goals more meaningful to the people who are building the product.

• Make it business or user focused when possible.  What will a user be able to do when we implement this feature?  What will a business area be able to achieve when we implement an enhancement?


• Make it focused on testing business assumptions and getting feedback.  Many times we do not know what users actually need or are willing to do (because even users don't know).  A Product Owner needs early feedback to test assumptions regarding value to users.


• Make it focused on reducing risk.  Proving out a technology or design is an important part of reducing risk.  If we learn that a technology is not going to meet our needs for performance, security, or scalability, we can change direction.  The earlier we change direction, the cheaper the cost of the change.