7 Sprint Goal Patterns for Building Great Teams, Part Two
Jul 16, 2015 by Vyacheslav Moskalenko
Menu
×
In the first part of this article you learned some specific terminology including: Sprint, Scrum Master, Product Owner, Definition of Done, and so on. This terminology is related to the Scrum framework, which was designed to deliver complex software products. Scrum is based on an empirical method that requires underlying principles to be implemented. Imagine two people in the same room, but each has different perceptions about the room temperature, and report accordingly. They are in disagreement, but if they had a thermometer to use, it would help them come to the same conclusion about the temperature . This is called empirical evidence. Empirical data provides the transparency that is critical for software development teams. Working software is a type of thermometer that can transparently track the progress and dynamics of product development.
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.
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.
Boundaries
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 Marshmallow Challenge. The rules of the Marshmallow Challenge are pretty simple: the team has limited materials, like spaghetti, and the goal is for them to build the tallest freestanding structure possible that can support a marshmallow at the top. They have 18 minutes to complete the task. It turns out that the winning strategy is to start with a small, working prototype and then constantly revise the structure as the team goes along, all the while keeping the marshmallow on the top, even through revisions. The riskiest strategy is to play the game in a traditional sequential way, i.e. starting with a comprehensive plan, design, construction and only at the end testing the structure see if it supports the marshmallow.
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:
A well-crafted Sprint Goal should be shared with all Scrum team members and integrate all the team’s best efforts into a single story line.
