Skip to main content

Sprint Goal understanding

Last post 04:02 pm April 30, 2023 by Alessio Valenti
9 replies
01:19 pm April 20, 2023

At this moment of the journey, we do not have a real/proper Product Goal, but a list of features we plan to deliver.

I have shown to the team that, according to the Scrum Guide, the Sprint commitment is the Sprint Goal and not the Product Backlog items assigned to that Sprint.

 

They still see those PBIs as a commitment, while the success of a Sprint is much more about the Sprint Goal.

 

Moreover, they consider Scrum as a toolbox, where you take "what you need"/"what you think it helps us", so they do not really think that the Sprint Goal is necessary - I already said that transparency and focus would benefit, and that it is so hard to be able to commit to a given number of PBIs as we already are not even able to do so.

In this case, we should probably just not call it Scrum, but I do not think this status quo should stay.

What would suggest in this situation?

 

Thank you very much in advance


01:46 pm April 20, 2023

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.


03:02 pm April 20, 2023

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?


09:52 am April 21, 2023

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?


12:18 pm April 21, 2023

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.


03:48 pm April 22, 2023

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.


04:34 pm April 23, 2023

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?


09:35 pm April 24, 2023

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.


12:39 pm April 30, 2023

we do not really have "one specific, dedicated" Product Owner working with our team daily

Strictly speaking, the Scrum guide doesn't mandate that (the same person working daily part). But one person, and only one, needs to be accountable. 

Who decides what the team needs to work on in general? Who sets the priorities? In other words: Who makes product decisions? That's the real product owner. It's their responsibility to define a product goal. And only they can do that. If there is no such person, which I doubt, then someone needs to explicitly fill that spot.


04:02 pm April 30, 2023

Fully agree with you @Oliver, thank you for your answer!


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.