Sprint Goal Template

Thanks Steve,

this is a really nice way to promote the importance of why.

All the positive examples are from non-software realns and the negative example is from a technology realm. Would you take the SAP example and actually write it like a good Sprint goal? The football example don't tell me anything about how to do that.

How do you write a sprint goal when the team needs to take on work requested by more than one customer, plus some technical items, in a single sprint?

I've created a "good" SAP example. Hope that helps

It may not be possible to write one that would cover all the items you mentioned above.

What would be possible is to identify the "If we deliver one outcome over the sprint, what would it be?" items and work with those. The team can work on all the other items, but they don't support the Sprint Goal and so their focus would be on items that do.

Thank you

This is all good and well if your team works on one project, but my team works on one product with many projects. A sprint goal under those circumstances is much more amorphous. HELP!

the sum of all the projects make the product, so the sprint goal will wrap up the overall benefits. If the sprint is usually on a single project, then, why don't split the team by project and have a sprint goal pero each section... all teams can share the same backlog, but not necessarily the same sprint backlog.

you described yourself... you are not working towards a common goal... your goal is to please many customers, so there's no specific product goal. I don't think even Scrum is made for this kind of scenario.
The fundamental problem in here is that the team is being sold or used as a production line, when it is not and the nature of the work is not that one either, so it is quite possible everyone in the team is frustrated :0 and the scrum implementation is creating a bigger gap between the client and PO expectations from what the team can do and how the team does it.
I will strongly suggest Kanban/Waterfall.

I love this.

I now use it when I'm delivering PSM I

The sum of the Sprint Goals, not "projects", helps to make progress toward the Product Goal.

"Each Sprint may be considered a short project" - Scrum Guide 2020, p8.

Yes, when we have multiple teams working on the same product, then they work from the same Product Backlog and create their own Sprint Backlog. The Nexus framework provides some additional structure to help many teams work on the same product.

Through the shared planning event across teams (Nexus Sprint Planning):

● a Nexus Sprint Goal that aligns with the Product Goal and describes the purpose that will be
achieved by the Nexus during the Sprint
● a Sprint Goal for each Scrum Team that aligns with the Nexus Sprint Goal
● a single Nexus Sprint Backlog that represents the work of the Nexus toward the Nexus Sprint
Goal and makes cross-team dependencies transparent
● A Sprint Backlog for each Scrum Team, which makes transparent the work they will do in
support of the Nexus Sprint Goal

The Product Goal tends to define the reason why the Scrum Team exists. If customers are making many requests, the Product Owner is there to work out what makes most sense in terms of short, intermediate, and long term objectives. Goals are there ultimately to provide focus (one of Scrum's values) for the delivery of value.

@stevetrapps:disqus suggestion is a great one: "If we deliver one outcome over the sprint, what would it be?"

A good Product Owner will have a very clear idea about the "why" of the Sprint to help the whole Scrum Team come to a conclusion by the end of Sprint Planning regarding what that impact and outcome should be. If not, the Scrum Master probably needs to coach the Product Owner to improve their agile product management capabilities.

Isn't this goal template the same as the User Story template: As a <customer> I want to <outcome>, so that <impact>. and the <event happens=""> is basically the Acceptance Criteria

I think one of the differences (between sprint goal and a user story) here could be how much work the team needs here to achieve the outcome (getting it from A to B).

The current situation could be a carport existed only.
There could be multiple user stories such as:
- As a car owner, I want to have some walls and a door built around my car so that bypassers won't see what's inside when they walked pass.
- As a car owner, I want the garage door to be lockable so that only people with the key can open it.
- As a car owner, I want to be alerted if my car is in the garage but the garage door is open.

In my example above the developer may drop the 3rd user story if they don't have enough time after finishing the first two.

There's a common pitfall where the Product Owner / stakeholder think that all the stories will fit and be delivered after they've done the journey / story mapping, without going back to the "why", or setting the "stop condition" when running their hypothesis.

I found this story splitting flowchart would helpful to guide the Product Owner and team members so that we don't fall into the "fixed time, fixed scope" trap.

Richard Lawrence explains that Stories don’t need to provide enough value by themselves to be worth shipping. You might need to accumulate several stories to move from valuable to marketable. We like Minimum Marketable Features, or MMFs, as a container for stories.