Sprint Goal understanding

What is stopping you from establishing a Product Goal and Sprint Goal?

If you have a Product Backlog that is ordered, something must be helping the Product Owner apply the appropriate ordering. You could use that as a starting point to start to formulate a Product Goal. From there, the Sprint Goal is often a stepping stone from current state to move closer to the Product Goal and can help the team move away from commitment to PBIs to commitment to the goal.

Since it doesn't seem like the effort to establish this is very high, would the team be willing to try for a few Sprints? Depending on how long your Sprints are, I'd suggest at least 4 Sprints, but perhaps 6-8 Sprints to see the value of commitment to goals.

In this case, we should probably just not call it Scrum,

I'd suggest there is a professional duty of care not to call it Scrum, and to avoid using Scrum terms of reference. Doing so will reduce transparency over what Scrum means, should it be needed.

The Scrum Guide says: "The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum."

but I do not think this status quo should stay.

Why not? What problems are occurring from the status quo or are at risk of happening? A Sprint Goal mitigates a significant risk or uncertainty in a complex challenge and gives a reason to Sprint at all. Who actually wants these outcomes, and is there a sense of urgency for change?

To @Thomas

Thank you Thomas for your answer! I agree with you, we should start from defining a Product Goal

To @Ian

Thanks for your answer, Ian!  When I said "I do not think this status quo should stay." I was referring to this lack of understanding/using the Sprint Goal. On one side, as a Scrum Master, I should let people understand Scrum and its concepts and apply them, otherwise the result is not Scrum; on the other side, the team might not accept some part of Scrum (e.g. because they do not see value in it or maybe our context is still not "complex" or not outcome focused enough), and I should not force that. How should I act in this ambiguous situation?

Hi Alessio,

While you "should not force", you can reinforce. Meaning you can find ways to reinforce the value of Scrum, and specifically for this case, the value that Sprint Goals can provide in terms of focus and coherence. This can come in the form of teaching, holding up a mirror, coaching etc. You may need to try a few different ways of communicating until you find one that resonates with audience. You are currently working in iterations, what data can you leverage? What are your observations from each iteration? Is there a lot of context switching? Is the team working together cohesively? Are there specific situations that have come up where Sprint Goals could have helped? 

All that said, Scrum isn't the only way of working. If this is not a complex problem requiring adaptive solutions or empiricism, it could be that another way of working is more appropriate for this product/service and team. If that is the case then don't call it Scrum as per Ian's line from above...

I'd suggest there is a professional duty of care not to call it Scrum, and to avoid using Scrum terms of reference. Doing so will reduce transparency over what Scrum means, should it be needed.

Hi there! It sounds like you're facing a common challenge many teams face when adopting Scrum - establishing a clear and compelling Product Goal to help them maintain focus and alignment.

It's vital to help your team understand that the Sprint Goal is supposed to be a means to achieve the Product Goal. The team should focus on delivering value by meeting the Sprint Goal, which should align with the Product Goal. Therefore, the Product Goal becomes an essential aspect of Scrum.

It's crucial to help your team understand that Scrum is more than just a toolbox. Instead, it's a framework designed to help teams deliver value by implementing a set of roles, events, artifacts, and values consistently. All of these aspects work together to help foster transparency, inspection, and adaptation.

To address this situation, I suggest the following steps:

1. Explain the importance of having a clear Product Goal that everyone understands and aligns with. Show them how it will help them focus on what matters most and make better decisions.

2. Facilitate a collaborative discussion with the team to define an overarching Product Goal that aligns with the organization's vision and goals. Ensure that everyone is on the same page.

3. Help the team create Sprint Goals that align with the Product Goal and use them to guide their work. Facilitate a discussion at the beginning of every Sprint to create and refine the Sprint Goal.

4. Continuously emphasize that the Sprint Goal should be the primary focus of the team's efforts, not the Product Backlog Items.

5. Remind the team that Scrum is a framework with essential components, including the Product Goal and Sprint Goal. These components work together to ensure that the team delivers valuable work consistently.

In summary, helping your team understand the value of the Product Goal and Sprint Goal and how they fit into the Scrum framework is essential. Through collaboration and continuous reminding, you can help them establish clear goals and align their focus towards value delivery.

just a question, what is preventing creation of of Product goal? If developers are indifferent or don't understand the purpose of Product goal you can collaborate with PO to create one and try educating developers?

If they actively resisting, then what's a problem?

Thank you Ryan, Lynn and Nicholas for your answers!

Those are going to help us, for sure.

To answer to Nicholas' great/appropriate question: 

what is preventing creation of of Product goal?

I would not define ours a Scrum Team, as we do not really have "one specific, dedicated" Product Owner working with our team daily, so me (as a Scrum Master) and at least one more person, we are covering some of the PO responsibilities/tasks.

So, I think I will now gather the team in order to create this sort of vision/team goal in terms of Product Goal, and then frame Sprint Goals based on that, trying to be outcome based more than feature based.