Crafting - measurable & outcome oriented Sprint Goal

Outcomes are certainly important, but I'd suggest that a good Sprint Goal harnesses the creativity of a team, so a significant risk or unknown is mitigated within a complex environment. In effect, the Sprint Goal makes the work in a Sprint Backlog more than the sum of its parts.

Your narrative does a good job of explaining how to craft outcome driven measurable goals.  But those type of goals should be more of a focus for an entire body of work which is commonly referred to as Product Goal. In my experience the goals you describe are more long term.  For example, you can increase the number of customers from 5 to 6 and get a 10% increase.  But that increase is meaningless to a business unless all 6 of those customers repeat business.  A Sprint of 2 weeks could be focused on the activities that are thought to be needed to increase the number of customers.  The goal for the Sprint would be to successfully implement some process or feature that enables you to experiment in ways to increase the customers.  In this case the Sprint Goal would be output based where the output supports the potential achievement of an outcome. 

@Ian Mitchell points out focusing entirely on an outcome can introduce other risks or shortcomings. The current Scrum Guide has this statement in the section that describes the Sprint

Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month.

In my opinion the following quotes from the Scrum Guide serve to define the Sprint Goal 

From Sprint Planning section

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

From Sprint Backlog section

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

These lead me to believe that the Sprint Goal is a tactical item that focuses the team on the activity needed to create an output.  

The new edition of the Scrum Guide introduces the concept of a Product Goal.  It is the commitment for the Product Backlog.  It is described in this manner

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

Your explanation better describes the Product Goal in my opinion.  In order to accomplish a Product Goal the team may need to try multiple options or experiments.  These options or experiments would be outputs of different Sprints and the Sprint Goals would be focused on creating them. 

Thanks a lot @Ian and @Daniel for taking time and sharing your views on it. :-) Really helpful 

Your explanation better describes the Product Goal in my opinion.  In order to accomplish a Product Goal the team may need to try multiple options or experiments.  These options or experiments would be outputs of different Sprints and the Sprint Goals would be focused on creating them. 

I totally agree with you , may be the case study examples I used might sound like not in direction of having focus on outputs at all or was confusing with respect to product goals.

But lets check some of the highlights in guide about product goal which is mentioned 15 times. 

Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month.

The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.

An Increment is a concrete stepping stone toward the Product Goal. 

If intrepreted , Sprint Goals are the steps or advancement towards the Product Goal. Product Goal is focussed on the outcomes and since Sprint Goals are the building blocks of it, isnt it relevant to have them outcome focussed as well even if they produce an output at the end ?

Sprints can involve activities , tasks, work that produces a real output but by keeping the focus on an outcome might bring more insights of why we need to develop an increment in a Sprint XX and how far/near are we from product goal.

If I recheck example again for outcome focussed goal - 

1. Evaluate Product - Build a feedback process with customers & check how happy they are with pizzas                                                                                                                            --- Isn't it an output like building feature where customers can vote/rate ?

2. Advertise Product- Send Pizza king pamphlets to all neigbouring PLZs (upto 500 apartments) about their newly opened shop                                                                              - Isn't this sounds like a task/activity ?

3. Increase Customer Reach - Evaulate own product prices against market & trends and accordingly add discounts/offers to increase new customers atleast by 20%.                           - This might be an outcome of data analysis , inspecting and adapting the prices. So, this might involve many tasks ,activities , creating outputs which leads further to achieve new customers.

As per me Sprint Goals do include all kinds of work that needed to make a progress towards the product goal. Producing an output is also an outcome of a sprint. But by keeping the focus on outcome might help in creating a clear Goal in line with higher product goal. Also adds flexibility in choosing in which way to achieve it.

Example - Enable customers to provide feedback on checkout process which will help us in improving it

Output 1 -  Develop NPS feature at the end of checkout  

Output 2 -  Call our customers and take down their feedback manually

Output 3 -  Send them auto emails for their feedback after checkout 

..... etc

all of them focus on same thing 'the outcome' , depends which of the above helps in creating high value forms our Sprint Goal --> "Develop NPS feature after checkout to enable customers to provide feedback "

@Harshal Rathee, thanks for sharing your thoughts on this. It's nice to hear your perspective.

Your posts and the contributions from Ian and Daniel have made me think in new ways about how a Sprint Goal and Product Goal may fit together.

But I still hold the view that outcome-oriented Sprint Goals are generally more helpful, as long as the right outcome can be pursued and measured within a sprint.

Over the past 6 months, my Scrum Teams have particularly embraced outcomes as Sprint Goals.

We had much more effective conversations at Sprint Reviews, because we could talk about the work done in relation to our business, the customers and end users.

By the end of the Sprint Review, there were times when we learned that we'd invested in things that weren't being embraced by our customers, but this didn't feel like failure. Teams are of course typically sad not to reach the Sprint Goal, but there's an overwhelming feeling of positivity that we're learning things early (in time for the next Sprint), so we're in a great position to ask "what now?"

Outcome-oriented Sprint Goals could serve as leading indicators of success, or validate assumptions in the strategy towards achieving the Product Goal.

If Pizza King have a Product Goal to increase profitability, they may have a strategy to achieve this by offering discounts in order to boost sales.

So it may be logical to spend the first sprint finding a way of using discounts that boosts sales sufficiently, whilst maintaining sufficient profit margins.

----

Example - Enable customers to provide feedback on checkout process which will help us in improving it

Maybe I misunderstood, but I think you were saying this is an outcome. In my view, this is an output with flexible scope.

An outcome could be "We gather feedback from at least one customer, after they have completed a sale".

The thing that makes this an outcome is that it relies on something that can only be influenced, rather than controlled: the customer's decision to provide feedback.

Thanks a lot @Simon for your valuable input !!

I second your thought  !!

Maybe I misunderstood, but I think you were saying this is an outcome. In my view, this is an output with flexible scope.

An outcome could be "We gather feedback from at least one customer, after they have completed a sale".

You are right, Goal is focussed on outcome on gathering the customer feedback.

So idea can be  - Enable customers to provide feedback on checkout process which will help us in improving it. But by also defining how and what way will make it clear and concise. Like i mentioned before as per me Sprint Goal for this can be - 

Sprint Goal --> "Develop NPS feature after checkout to enable customers to provide feedback "

So we know why we need to develop the feedback feature  , we know what way is best solution for us and our customers, how can serve as a plan to deliver it.

Sprint Goal --> "Develop NPS feature after checkout to enable customers to provide feedback "

I would generally still encourage an outcome-oriented goal instead.

This Sprint Goal locks the team into plan A for gathering feedback (they must build the feature, even if it turns out not to be the best option), and it does not say anything about how much it is being used.

A better Sprint Goal might be Have at least X customers provide feedback via the after-checkout NPS feature, because that already allows a conversation about how it's being used by customers.

An even better one might be to exclude the specific solution from the Sprint Goal altogether.

Just because a solution isn't included in a Sprint Goal, it doesn't prevent a Scrum Team from aligning around a specific plan for achieving it; but it does allow them to change plans if the first option proves to not be the most suitable.

Just because a solution isn't included in a Sprint Goal, it doesn't prevent a Scrum Team from aligning around a specific plan for achieving it; but it does allow them to change plans if the first option proves to not be the most suitable.

When can an organization or a team know that their solution is the most suitable one ?

If intrepreted , Sprint Goals are the steps or advancement towards the Product Goal. Product Goal is focussed on the outcomes and since Sprint Goals are the building blocks of it, isnt it relevant to have them outcome focussed as well even if they produce an output at the end ?

I won't disagree with this but the outcome has to be something that can be measured and validated within the Sprint. I have found that teams struggle with that but have success at small tactical goals that support larger strategic goals. As with anything in today's agile world it boils down to what makes the most sense for the team doing the work.  I appreciate your opinion and I'm sure that at some point I'll probably work with a team where it works.  I just haven't had that chance yet. 

When can an organization or a team know that their solution is the most suitable one ?

When the stakeholders tell you, either through direct communication or by usage metrics. Another way is the oldest form of flattery....when your competitors try to copy it.  

When the stakeholders tell you, either through direct communication or by usage metrics. Another way is the oldest form of flattery....when your competitors try to copy it.  

Brilliantly put!

In the context of having an outcome-oriented Sprint Goal, then I would expect the Scrum Team to pay attention to this throughout the sprint, by looking for opportunities to release early and throughout the sprint, and by ordering the Sprint Backlog in a way that allows the most important or time-critical learnings or realized value to be gained first.

It might even prove necessary for the Developers to obtain new skills, such as product-discovery or analysis, in order to inspect and adapt effectively in response to these additional learnings.

A better Sprint Goal might be Have at least X customers provide feedback via the after-checkout NPS feature, because that already allows a conversation about how it's being used by customers.

An even better one might be to exclude the specific solution from the Sprint Goal altogether.

Just because a solution isn't included in a Sprint Goal, it doesn't prevent a Scrum Team from aligning around a specific plan for achieving it; but it does allow them to change plans if the first option proves to not be the most suitable.

Yes i agree, its measurable and outcome oriented. Like in the analogy i stated about increaing the customers by X% by offering discounts. Also for such outcome oriented Goals , solution needs to be validated within the sprint by releasing to an environment where desired inspection can happen ( like you mentioned above).

But along with inspection , the Goal also needs to be measured within the Sprint. Now this can add a bit of uncertainity for a team to decide on the other solutions or change in plans. So, having a solution in a outcome oriented Goal fosters focus on when to deliver and how long to measure. But at the same time it entirely depends on the solution and the product. For me outcome oriented Goals adds more value whether with solution or without. And by adding measurable criteria to it,  brings them to life. ;-)