Writing a Worthy Sprint Goal (9 Characteristics)

If getting your team to agree to a Sprint goal is like pulling teeth, check out these tips for defining valuable Sprint Goals.

What’s a Sprint Goal Again?

The Scrum Guide refers to the Sprint Goal as the “why” for that Sprint.

The sprint goal is a single, concise, overarching objective that describes the purpose of a sprint.

Why Should my Team Care about Sprint Goals?

Sprint Goals have four primary benefits.

1. Shared Understanding

It can be challenging to get the Scrum Team moving in the same direction. Having a highly visible and collaborative statement that sets the objective for the Sprint can help cut out some of the waste incurred due to miscommunication and misunderstanding.

2. Sets the Focus for Daily Scrum

A Sprint Goal can help to combat the status meeting anti-pattern of daily standups. Measuring progress toward the Sprint Goal and framing discussions around what remains to satisfy the objective can help ensure teams plan their day around the most valuable work.

3. Elevator Pitch for Stakeholders

Having a brief, concise statement to share when encountering stakeholders in the wild can increase transparency and cut down on miscommunication.

In low trust or low transparency cultures, it’s common for leadership to misconstrue poorly worded comments uttered by members of the Scrum Team. Misunderstandings lead to waste and the potential to further damage trust. Having a consistent way to refer to the work in progress can eliminate some of this unnecessary drama.

4. Focus on the Need, Not the Ask

When it comes to software, it’s all too easy to meet the technical specification without accomplishing the customer’s actual need.

We run a similar risk in our Sprints. The team might do precisely what they set out to do but somehow miss the objective that the Product Owner had in mind.

A Sprint Goal provides a more general idea of what the team wishes to accomplish while leaving enough flexibility to determine the best path for implementation.

The 9 Characteristics of a Great Sprint Goal

Assuming you believe Sprint Goals can be beneficial, there are nine characteristics that your team should strive for that will ensure your Sprint Goals provide maximum value.

Brief

Keeping the Sprint Goal brief serves two purposes:

1. Easy to Remember

We’d prefer the objective to stay top of mind since this is what we’ll be working to achieve for the next two weeks.

Memorable phrases are also more likely to be remembered when encountering a member of executive leadership. No one will want to ask a stakeholder to wait while we check our email to find this Sprint’s goal.

2. Ensures Understanding

Have you ever tried to paraphrase the main topic of a book? Perhaps you’ve been attempting to restate a passage from a book in your own words.

“I apologize for such a long letter - I didn’t have time to write a short one.”

-Mark Twain

I follow a progressive summarization technique for reading that helps retain and remix what I’ve read. I can assure you that it’s much harder to put something into your own words because a prerequisite to rewording something succinctly is a deep understanding of the topic.

One

One of the main benefits of having a Sprint Goal is to establish where the team should focus. If you have more than one Sprint Goal, you’re defeating that purpose.

“When everything is a priority, nothing is a priority.”

-Karen Martin

If your intuition tells you that your team needs more than one sprint goal, I will challenge you to determine the root cause of that assumption. Instead of declaring multiple Sprint Goals, seek first to alleviate the cultural or process issues that compel you to split focus.

For instance, if you find a lot of unrelated work is taking on, it may make more sense to split into smaller teams. Alternatively, you may choose to tweak portfolio prioritization so that work flowing to the team is more closely related. Instantiating WIP limits could also help funnel the work down into a more focused flow.

Also, keep in mind that the Sprint Goal’s purpose isn’t to summarize everything we’ll get done this Sprint. When the sprint goal is satisfied, we don’t just take a siesta for the rest of the timebox. The team may have work beyond what is required to accomplish the Sprint Goal. We’re just trying to come up with a succinct statement that helps us understand the priority.

Negotiable

You’ll want to word your Sprint Goal in a way that allows for some negotiation.

Complete the top four user stories

This goal doesn’t allow any leeway. We will either succeed or fail.

Deliver a proof of concept for the cheesecake ordering page.

This goal is less prescriptive and will allow the team to better-informed decisions as they learn more information throughout the execution of the Sprint.

The cheesecake ordering page might be a fully functional page on a website, or it could be a rough sketch on a napkin. The team has some flexibility to determine what is possible and what would give the customer the most opportunity to provide feedback. We allow the team to decide how to balance progress against the potential waste of throw-away code.

Understood

Everyone on the team should understand the goal; otherwise, different team members will be working toward divergent targets.

If the team collaborates when defining the Sprint Goal, it is more likely that everyone will understand it.

We should strive for no team member left behind.

SMART

SMART is a common acronym used for goal setting. The letters stand for specific, measurable, attainable, realistic, and timely.

Let’s break down how these guidelines apply to the Sprint Goal.

Specific

Your sprint goals should be specific enough to eliminate confusion.

Implement a cheesecake selection page.

While on the surface this goal sounds specific, it’s actually a bit vague. Technically if we have just a blank page labeled “Select a Cheesecake,” that could arguably satisfy the requirement.

The difficulty is in balancing between specific and negotiable. We’re aiming for a level of specificity that will eliminate ambiguity and leave options for how to accomplish the goal.

Allow a user to browse our three-thousand cheesecakes by our seventeen categories and add multiple items to the cart.

While the previous goal was a bit vague, this second attempt doesn’t leave us much wiggle room for negotiation.

Not only does that last Sprint Goal cover a lot of functionality, but it’s also excessively specific. A Sprint Goal should capture the essence of the increment that we hope to deliver. It’s less about trying to maximize the amount of work done in the Sprint and more about validating as many assumptions as we can with the least amount of effort.

It might be good enough to allow the user to browse ten cheesecakes in two different categories. Limiting the first increment to only a subset of the data may reduce the feature’s delivery time. We don’t have to worry about building or obtaining all of the creatives. We don’t spend time on pagination that users may not need if we end up going in a different direction from the initial design.

The top product backlog items might all be related to building out the UI for browsing cheesecakes. Still, with the context that we should be focusing on taking small steps and obtaining validation from users and stakeholders, we can translate the product backlog items into a more practical goal. It seems like the next thing that we want to validate is that the UI for browsing and selecting cheesecakes is going to work. So, why not have that as the goal?

Validate the design of the cheesecake selection page.

At the end of the Sprint, it should be clear whether we’ve validated the design with stakeholders. The team also has some options on how to accomplish this goal. They could use mock-ups, paper prototyping, or build a fully functional page. They could progress through all three of those phases throughout the Sprint.

No rule prevents us from accomplishing the goal early or building on the work that satisfied the goal. If we get sign-off on a paper prototype on day one, we don’t just stop and take a nap for the rest of the Sprint.

Measurable

The point of a goal being measurable is that there is no question about whether you’ve achieved what you set out to achieve.

Validate the design of the cheesecake selection page.

What counts as validation? Is it just that the product owner has signed off? Perhaps some key stakeholders wish to sign off on the design. Maybe we want our UI/UX expert to validate that the product aligns with best practices.

Validate the design of the cheesecake selection page with all stakeholders, the PO, and the UX team.

This goal is a bit more measurable. At leaset we’ll know when we’ve achieved this sprint goal.

Attainable

An attainable goal is a goal that is technically possible to achieve.

Depending on how we want to define “stakeholders,” getting all stakeholders to validate the design of our cheesecake selection page may not be feasible.

It’s likely more attainable to say:

Validate the design of the cheesecake selection page with three stakeholders, the PO, and the UX team.

Realistic

The difference between attainable and realistic is splitting hairs, in my opinion. Attainable is determining whether any team can accomplish the goal. Realistic is determining whether our team can achieve the goal.

It might be attainable for some teams to get a whole UX team to sign off on their initial design, but we happen to know that half of our UX team is out on vacation this Sprint. So, a more realistic sprint goal might be:

Validate the design of the cheesecake selection page with three stakeholders, the PO, and one UX expert.

Timely

SMART goals should have a time component. If your team uses sprints (which the term Sprint Goal implies), your timeline to accomplish the goal is within the Sprint.

Validate the design of the cheesecake selection page with three stakeholders, the PO, and a UX expert (before the end of the sprint).

If, for some reason, your Sprint Goal is dependent on some other timeline, that should be part of the goal for the sake of clarity.

Validate the design of the cheesecake selection page with three stakeholders, the PO, and a UX expert in Wednesday’s big meeting.

BONUS

If you want an easy way to remember all of these characteristics, just remember “BONUS.”

• (B)rief
• (O)ne
• (N)egotiable
• (U)nderstood
• (S)MART

Yeah, that S is a bit of acronym inception. But if you’ll allow it, you’ll have a tidy mnemonic device to remember the characteristic of a great Sprint Goal.

SMART should be easier to remember as you’ve likely run into this acronym before.

• (S)pecific
• (M)easurable
• (A)ttainable
• (R)ealistic
• (T)imely

Works Consulted

• Scrum Guide
• Creating Great Sprint Goals
• The Product Owner’s Guide to Effective Sprint Goals
• The Sprint Goal: Why It Is Critical and How to Get It Right
• Writing Good Sprint Goals
• Sprint Goals — What Do They Really Need (With Examples)
• The 11 Advantages of Using a Sprint Goal
• Getting to Done: Creating Good Sprint Goals

TLDR

If you’ve tried Sprit Goals in the past and you’ve found them to be pretty painful, try applying the concepts in this post to help make them less of a drag for your team.