According to the latest Scrum Guide, “the Sprint Goal is the single objective for the Sprint” and represents a “commitment by the Developers” to deliver a usable increment of product to the business by the time of the Sprint Review. Created during Sprint Planning, the Sprint Goal is a common goal for the entire Scrum Team, it “creates coherence and focus, encouraging [them] to work together rather than on separate initiatives.”
How does the Product Owner create a Sprint Goal with a Scrum Team? Here are five simple steps to follow:
- Begin by identifying the Product Goal. Depending on how the role of Product Owner has been implemented in your organization, the Product Owner can do this by themselves or in collaboration with the stakeholders.
- Consider what are the series of key outcomes the Scrum Team must deliver each Sprint in order to realize the Product Goal. When used properly, each Sprint Goal represents one potential step towards realizing the business objective embedded within the Product Goal. At this stage, it is important to pay attention to how each Sprint Goal improves the lives of the customers or end users, not to create a list of outputs that may have little, or no, impact. I recommend Product Owners collaborate with the Developers to select a series of Sprint Goals that make sense both from a business and technology perspective.
One common error I see at this stage is that many Scrum Teams have a one-to-one mapping of their Product Backlog items to their Sprint Goals. At the bottom of the Product Backlog, this may be true since the Scrum Team has yet to define any details for those Product Backlog items. At the top of the Product Backlog, though, this is not the case because there is a one-to-many relationship between a single Goal and Product Backlog items. My recommendation is to have from four to six Product Backlog items to support a single Goal at the top of the Product Backlog. - Reevaluate the Sprint Goal with the Scrum Team during Sprint Planning. As the Scrum Team develops the product or service, they will learn more about the work, the product, the market and the technologies which means the Product Backlog items, or their order, will change. Any change in the Product Backlog implies any potential Goal(s) defined up front may be altered. The best Product Owners do not resist this change but update their Sprint Goals just-in-time. I strongly urge Product Owners to act in the moment to craft new Goals based on their conversations with Developers and the four to six Product Backlog items which were selected during Sprint Planning.
- Write a single Sprint Goal of no more than ten to fifteen words. Like the product vision, the Sprint Goal should be a short phrase which encapsulates what the business will receive as a result of investing the Scrum Team’s time for an entire Sprint. The best Goals are written in language comprehensible by a business stakeholder. When the Goal is written in business language and describes a meaningful outcome desired by customers and end users, the Sprint Goal serves as an invitation to the Sprint Review. Stakeholders who are interested in the Goal will show up and offer their feedback. Those who are not interested will take a pass and attend when the Goal addresses a topic which requires their involvement.
- Take a confidence vote with the Scrum Team. This last step is a sanity check to ensure the Sprint Goal makes sense and no one is overcommitting. In Scrum, we do not begin a Sprint knowing that it will result in a version of the product that is unusable and/or cannot be delivered by the end of the Sprint. My favorite technique to use in these situations would be Roman Voting but many people like Fist of Five or Decider/Resolution. If the confidence vote reveals the Goal is not attainable, the Product Owner and the Developers must reduce the scope of the Sprint until everyone feels comfortable committing to the Goal, assuming there is time remaining in the Sprint Planning timebox. This final negotiation may alter the Product Backlog items and/or Goal.