For years and years, I’ve been talking about the importance of Sprint Goals in the fabric of Scrum team execution. They:

• Help to guide the focus and conversations at the daily standup and the team’s daily activity;
• Help to focus the team’s sprint planning towards an outcome;
• Help to identify the purpose and focus of the sprint demo;
• Help the Product Owner and the team in making sprint content trade-offs if the run into difficulties;
• Ultimately help the team define what “success looks like” for each and every sprint.

Given that definition, my clients usually start looking at Sprint Goals in a different way. I see them as being very powerful mechanisms for focusing the team’s efforts and I hope you start to as well.

What I usually tell folks is this:

You have a sprint planned in your backlog. It’s a series of stories that you’ve worked with the team towards a single theme or thought. You envision the demo you’re going to run – what workflow or flows, what feature addition will you highlight or what problem will you be solving?

Ok.

Now craft an email inviting the entire company to your demo. Pretend not everyone is a software engineer or a BA. So you need to write the email in clear English to entice them to come. It’s an “elevator pitch” that succinctly explains the value the team is about to deliver.

• What is the headline of your email?
• What do you say in the first 1-2 sentences?

THAT is your Sprint Goal. 

Does the goal need to represent ALL of the work in the sprint? I’d say no. It needs to represent the “majority” of the work and represent your “theme” for this sprint.

Can it be a “list” of stuff?

Perhaps. But a very, very short list. Perhaps 2-3 distinct things that are “tied together” in some way.

The important thing is you thoughtfully communicate a goal to your team in each sprint. It’s the measure for sprint success AND it should provide “wiggle room” so that the team can achieve it in a variety of ways.

For example, IMHO these are CRAPPY goals:

• Complete 10 stories for this sprint
• Work 546 hours this sprint
• Complete these 15 bugs this sprint
• Complete story #4, 345, 23, 198, 67, 324, and 56 this sprint
• Complete the customer spend money workflow

Here’s an example of a BETTER goal:

Our goal this sprint is to continue expanding the customer (patient) workflow for our Hospital Information System. This sprint we’re adding advanced health assessment data (2-screens) with file attachments and patient doctor connectivity.

And here’s a goal related to the past and future:

Our goal last sprint was to implement the patient workflow for emergency room entry. This sprint we’re focusing on connection to and validation of insurance information, coverage, and payment risks. Next sprint, we’ll focus on capture of visit information related to treatment. Which might extend beyond a singly sprint. This is where we’re going!

Sprint Demo or Review

Do you see the direct implications to the sprint demo? I sure hope so. I love to use the Stephen Covey habit of – Beginning with the End in Mind, as illustrating the purpose of the Spring Goal.

It’s a unifying statement, a purpose, a path or journey, a goal that constrains and focuses EVERY action within the sprint.

And ultimately, it’s what we show and what we’re expecting to gain valuable feedback on.

But they also help with…

Quite often folks have a limited view of their goals. Sure, we align them with a sprint and then talk about attainment at the end. I have a difference experience and view to the value of goal-setting within agile teams.

Once you establish your sprint goals, I want you to:

• Focus on them in each daily standup meeting. Having everyone “check-in” on their progress to the goals. I want to focus less on individual achievement and more on team progress towards each goal.
• If you find that you’re slipping from a goal, conversation should immediately pivot towards corrective action(s). Or on making scope micro-tradeoffs towards maintaining the goal.
• Hallway conversations should also be goal aligned; with everyone from team members, outside teams, managers & leaders, and stakeholders talking to the team about “progress to goal” and any associated risks.
• The sprint review / demo should be entirely focused towards the goals the team has delivered. And if anything is missed, the risk mitigation strategies that have been implemented.
• And finally, the team’s retrospective should discuss goal-setting, goal alignment, goal attainment, and goal-setting improvements.

What I’m alluding to here is that a focus on sprint goals, and goal-setting in general, starts to shift the organizations culture towards value, predictability, quality and team health focus points. In other words, the overall organizational DNA shifts.

Or it has the potential to drive those sorts of changes.

Wrapping Up

I hope all Scrum Product Owners come to the table in each and every Sprint Planning meeting with a thoughtful, valuable, and focused sprint goal or small set of goals.

Why you might ask?

Well first, because it’s their job. And second, to help their teams…focus.

Stay agile my friends,

Bob.