Scrum Pattern | Sprint Goal

How important is the Sprint Goal?

The goal of Sprint is to deliver value to stakeholders. However, We can not create the maximum value by following an SBI (Sprint Backlog Item, Sprint To-Do List; e.g., tasks) list only.

Suppose teams draw up a plan according to individual tasks or deliverables. In that case, it is easy to select a to-do item to work on individually during the Production Episode (one of the Scrum Patterns). In this case, there is a lack of innovation. Innovation is generated by interacting with individuals with different perspectives on the work. When work is done independently, it is as if an invisible office cubicle is created that prevents the continuous exchange of ideas (which are significant not only for one developer but also for many developers and even for the whole team). Without adequate interaction and communication, teamwork can be impacted.

The team may need to re-plan parts of the ongoing Sprint to ensure that the team can deliver value to stakeholders at the end of the Sprint. Over time, the team may gain new insights into the work, and new jobs may be produced, at which the team should adjust the plan accordingly. If the team still follows the original plan, it may not be able to carry out the maximum value. It is also common for teams to be unable to complete each SBI in the Sprint Backlog for more work is required than anticipated, and this may need to be achieved through re-planning if the team still wants to do everything they can to deliver value. Reprogramming Sprint requires thoughtful consideration and takes time.

In another case, the team needs critical technical expertise on "how to implement a PBI (Product Backlog Item)" to develop it more confidently. For example, a developer (or even a product owner) may need a technical prototype to test a proposed structure or learn about some technologies' performance characteristics. This is also referred to as a PBI, but this type of PBI aims to help the team gain additional knowledge rather than complete a task. Such a technical prototype is exploratory and time-consuming, so it is essential to the success of the Sprint, and its completion is critical to achieving the Sprint goal. (such a PBI is what we call a Spike.)

In some cases, the maximum value may not simply be the achievement of a PBI. for example, the ultimate value to the team is to increase the financial revenue that each Sprint can generate, but the team is only using one PBI to achieve this value. On the other hand, the majority of the value of a Sprint comes primarily from one key PBI among many.

Therefore, the Scrum team wrote a short statement (Sprint goal) for the value to be created during the Sprint and committed to it. This will be the focus of all work in the Sprint.

The entire Scrum team works together to create Sprint goals. The product owner guides the creation of the Sprint goals, as they are familiar with the next steps in achieving the product vision and creating the maximum value. The Scrum team should commit to the Sprint goal as something always within reach.

How does the Sprint goal work?

The Scrum team can select a PBI for a Sprint based on the Sprint goals, which are even more important than the sum of the individual PBIs. Sprint goals establish coherence between two PBIs (not a collection of scattered PBIs), which helps create valuable product increments. A good way to initialize a Product Backlog is to express it as a list of many Sprint goals by the product owner and development team working together.

In order to accomplish their goals, the autonomous team members must be able to manage themselves. The Developer-Ordered Work Plan (one of the Scrum Patterns) states that the development team is free to organize their work during the production phase in any way they deem appropriate. The sprint goal is the only mechanism used by the product owner, with the developers' agreement, to influence the potential sequence of work for the development team (urgency is inferred from the information conveyed by the Sprint goal).

During the Sprint planning meeting, the Scrum team determines what they want to achieve by the end of the Sprint. In short, this is the reason why Sprint goals exist. The development team uses the Sprint Backlog to define the details of how this Sprint goal can be accomplished. If the development team believes they will not be able to meet the Sprint goal, they should re-consider the Sprint goal with the product owner. A key output of the Sprint planning meeting is that the development team should be able to explain how they can meet the Sprint goal and how they know they have achieved it. The ability to explain comes from a thorough understanding of the work ahead, which increases the probability that the team will accomplish the Sprint goal in the Sprint.

The development team commits to the Sprint goal. This Sprint goal helps the development team be united in their commitment and helps stakeholders build trust in the group.

Sprint goals should be visible to the team, for example, by placing them on a Scrum board or other information radar. In order to achieve Sprint goals during the Sprint, the development team should ensure that the Sprint Backlog keeps reflecting the latest work status. Sprint Backlog progress during a Sprint is like progress on a football pitch: the value is focused on the goal, although each progression brings the ball closer to the goal. Sometimes, completing a Sprint goal (in one way or another) is possible without completing all the SBIs. This helps the team deal with unexpected events and allows the developers to shift their work plan during the Scrum meeting (provided the goal remains the same). For instance: an unexpected obstacle can threaten the development team's ability to deliver a complete Sprint Backlog. in this case, the team adopts the Sprint goal as a "Plan B" without spending a long time re-planning. A study by Carnegie Mellon University[1] reported that teams that prepared for interruptions in advance were 14% better than teams that did not prepare in advance. Teams that qualified for interruptions completed an uninterrupted task are about 43% faster than teams that did not. It's a mindset of preparing for the unplanned: when unexpected events occur, the team can move to a new configuration to handle them without external coaching.

It is theoretically possible to achieve a Sprint goal with only a small proportion of the PBI completed for each Sprint. However, this should be uncommon as the Sprint Backlog should be aligned with the Sprint goal. If it is not, there is a severe problem with the value flow.

Velocity helps teams know if they are doing things the right way (we assume that speed increases as they do things in the right way.) Sprint goals help teams to make sure they are doing the right things. It is about getting the 'why' of what the team is doing so that they can stay focused when things change.

Are there other effects of Sprint goals?

Jeff Sutherland adds that as well as keeping teams focused, Sprint goals also promote the use of Swarming (one of the Scrum Patterns). Can we get everyone to do one thing together?

“In 2007, Palm developed a web-based operating system in Silicon Valley, a system that Hewlett-Packard later acquired. The team did well for the first few Sprints, but they seemed to run into difficulties after a few Sprints. PBIs were not completed. The developers were poorly motivated and went home early. I asked the Product Owner and Scrum Master to spend an hour interviewing the team members to find out why they were not motivated. We found that the reason for their lack of motivation was that they didn't know what problems these low-level PBIs were trying to solve.

We spent an afternoon cleaning up the Product Backlog, which clearly showed the connection between the higher-level and lower-level stories. Once the developers realized that Sprint's goal was to improve the performance of the web OS by 10%, they were motivated to complete the lower-level stories, and the work rate returned to normal.

It is critical for developers to know why PBI should be implemented, especially for expert developers, who might be unmotivated if they cannot find a reason for their work.”

Sprint goals are linked to the value of the product. Teams can define Sprint goals in terms of process goals. For example, by pairing programming to complete all programming or being on time for Scrum meetings. Repeatedly promoting Sprint goals can motivate teams to achieve higher levels of engagement. In turn, the Happiness Index can be an effective tool for defining or proposing Sprint goals.

Who is the author of Sprint Goals?

Ken Schwaber introduced the concept of Sprint goals and Mike Beedle in 2001 ([2], p. 48).

Reference :

[1] Bob Sullivan and Hugh Thompson. Gray Matter. “Brain, Interrupted.” In New York Times, 5 May 2013, page SR12, http://www.nytimes.com/2013/05/05/opinion/sunday/a-focus-on-distraction.html (accessed 2 November 2017).

[2] Ken Schwaber and Mike Beedle. Agile Software Development with Scrum (Series in Agile Software Development). London: Pearson, Oct. 2001, p. 48.