A measured product goal provides agreement between different roles and parties and makes the process more transparent. In the most recent version of the Scrum Guide there are some changes to the rules for the Daily Scrum meeting. In the updated version, team members are instructed to think first about the Sprint Goal before anything else. The Sprint Goal serves as the thermometer for Daily Scrums, helping development teams adjust and correct plans long before the final meeting, which is called Sprint Review. Let’s explore a few Sprint Goal patterns.
Finding a Jewel in a Haystack
Taking something apart and letting it ‘decompose’ is an effective way to solve bigger problems. Big software development problems are often marked as epics. Epics usually involve going through the requirements elicitation process, and end with breaking the backlog up into multiple, smaller stories, but this massive number of stories and detailed requirements can obscure brilliant objectives. Let’s see an example:
The Development Team would take this text into their Sprint to decide what to focus on first. Let’s give them some parameters.
Sprint Goal: Allow the User to See Flight Options
This provides a clear direction to head towards. It involves developing the value declared in the Sprint Goal first, and then focus on developing other stories to enhance that value. Sometimes the focus gets lost. Often a development team has the tendency to start Sprint with the most interesting requirements, and then tack a purpose onto it at the end. In this situation, the Product Owner needs to reinforce the value in the Sprint Goal.
A number of projects are dedicated to the support phase. Support has distinctive characteristics: frequent changes in priorities; the inability to plan long-term due to urgent production issues; critical enhancements; emergency releases and patches; intensive communication with end users; different levels of severity, etc. How would one define the Sprint Goal for a Scrum Team that is providing support for an existing version of software? It might seem impossible, but setting focus and boundaries will help.
Sprint Goal: Improve the Performance of Financial Report Generation
In this example, the development team focuses on performance issues during the Sprint. This will help the Scrum Team deliver more comprehensive and consistent results, as well as push them to think more about a single solution for the series of interrelated production fixes. The Product Owner can suggest replacing one issue with another if it’s discovered that other Product Backlog items are impacting software performance more than initially planned or anticipated. New items could easily hit the Sprint Backlog if they fit the boundaries defined by the Sprint Goal.
The Marshmallow Challenge
This pattern borrows from the idea behind the
This can be a useful demonstration for defining a Sprint Goal when your project has its own marshmallow on the top. For example, say you have to develop a product that will generate a specific financial report. To get it right you have to develop some functionality to edit and pre-calculate different parts of the report. One strategy is to plan all the report components up-front and develop all the components, and only then develop the report itself. The marshmallow strategy, on the other hand, is to start immediately from the report prototype and then improve it throughout the process, by completing new report components for each new Sprint, always making sure that the report is in a working state.
You can see that each Sprint team selected a number of User Stories (US). However, each set of User Stories has its own Sprint Goal, which is focused on a demonstration of the final report.
Setting a strategic target for the Sprint Goal and maintaining it on a Sprint basis will help you avoid undesirable variances in product development, as long as there is a distinctive desired outcome.
Connect to the Epic
This is the most common way to define the Sprint Goal. I would recommend it when a Development Team is working on multiple epics (small projects) at the same time, which is scattering product focus and affecting time to market (lead time) of the single epic. In this case we select one epic as a Sprint Goal and then the Product Owner is allowed to change priorities or add new requirements connected to the selected epic.
Sprint Goal: Keep News Updated on the Corporate Website
The Bottom Line
The Sprint Goal is an important practice in the Scrum framework, because it improves focus, courage and commitment, all of which stem from intrinsic motivation. Be on the lookout for bad patterns resurfacing in crafting a Sprint Goal. Bad Sprint Goal patterns limit the Scrum Team from taking advantage of the benefits of Agile development and reinforce old principles from a traditional management toolbox, which could lead to failure.
There are a number of good patterns to follow in crafting a Sprint Goal, and they reinforce the following:
- Opportunity for PO to introduce changes
- How the team perceives its success
- Team spirit and motivation
- Sprint outcomes