who creates the Sprint Goal?

The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.

It refers about achieve the Sprint Goal but question is about who crafts SG and scrum guide said:
"After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal"
so Scrum Team crafts a SG :)

Thank you :)

I just wanted to iterate my understanding of the sprint goal creation process, The questions asked are quite tricky at times

The Initial objective of the sprint is really something which the Product Owner brings onboard, The Scrum Guide specifically points this out by saying that the PO discusses the objective that the sprint should achieve, which really involves completing some of the product backlog

However the development team then reviews and based on its capacity and scope, agrees on some portion of the backlog items for the spring, This becomes the Sprint backlog,

Now the above Sprint backlog may not be the exact items from the backlog which the PO had in his/her mind to achieve the original Objective which he/she had in their mind, but based on the development teams item list, the scrum team collectively now updates this objective and this becomes the sprint Goal.

So i agree that the sprint goal is crafted by the entire scrum team, but the origin of the objective was the PO

I think that is a good analysis.

I do agree that Scrum team will be responsible for Sprint goal.

On the same lines, Scrum Team should be responsible for creation of Sprint Backlog .. would appreciate if someone can confirm on this.

" In Part One, the Team and the Product Owner may also devise the Sprint Goal. This is a summary

statement of the Sprint objective, which ideally has a cohesive theme. The Sprint Goal also gives the

Team scope-flexibility regarding what they may actually deliver, because although they may have to

remove some item (since the Sprint is timeboxed), they should nevertheless commit to delivering

something tangible and “done” that is in the spirit of the Sprint Goal" (Scrum Primer 2.0).

Are there two answers corresponding as to who "may" (or) "should" devise the Sprint Goal?

In scrum guide, it has been clearly mentioned that 'During Sprint Planning the Scrum Team also crafts a Sprint Goal'. Period.

Actually, it's not created by PO only, It is created during the Sprint Planning meeting by entire the Scrum Team.

PO creates a PBI and he would be sure what stories needs to be moved to Sprint backlog  to achieve the Sprint Goal..

So based on his understanding the development team would choose the Items to the Sprint backlog is my understanding correct ?

Suresh, what does the Scrum Guide say about how the Sprint Backlog is formed?



Also, who does the Sprint Backlog belong to?

What is the role of the scrummaster in crafting the sprint goal?

scrum team creates the sprint goal which is totally influenced by the PO objective what she wants to achieve in the sprint. 

@saskia they make sure SG is attainable n SMART. Dev team should make vague sprint goal for the sake of having it .

Who creates the Sprint goal:

https://medium.com/serious-scrum/scrum-who-determines-the-sprint-goal-497dd3238b6

What is the role of the Scrum master towards creating a Sprint goal? This is not clear in the Scrum guide. The Scrum guide merely mentions that "During Sprint meeting, the Scrum team crafts the Sprint Goal".

While it is clear that

- the Product Owner comes to the meeting with a set of Product Backlog items and an objective.

- a discussion with the Development team on what tasks can be added to the Sprint Backlog leads to the creation of the actual goal which may not be the same as the one suggested by the Product Owner initially.

Thus to me it seems like only the Development team and Product Owner are key to creating a Sprint goal and am wondering what the Scrum Master contributes in this regard

Take a look at the section in the Scrum Guide, where it references "Scrum Master Service to The Product Owner", and below that "Service to The Development Team". 

The Scrum Master may facilitate Sprint Planning if needed, teach everyone on the Scrum Team about the Sprint Goal and why it is needed, ask open ended questions if the Scrum Team is struggling to come up with a Sprint Goal (i.e. coaching), uphold Scrum by ensuring there is a Sprint Goal, help the Product Owner find Product Backlog ordering techniques so there can be some cohesive set up PBIs leading up to Sprint Planning, etc.

Thus to me it seems like only the Development team and Product Owner are key to creating a Sprint goal and am wondering what the Scrum Master contributes in this regard

The Scrum Guide says:

The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

In your experience, how readily do team members grasp this idea of "coherence", and how easily do they master the ability to craft good Sprint Goals?

Actually the Sprint goal is created during the sprint planning with the entire scrum team. Dont forget that the Product Owner Is  part of the scrum team. He's responsible for tracking the business progress of the product and he will to up  and discuss with the team the objective of the sprint the he want to achieved.

Base on what the Product Owner wants , the team will discussed, reach a consensus and set a Sprint Goal.

As Scrum Master, I have contributed to the creation of Sprint Goals by asking questions such as:

• Is this goal delivering value that is needed?
• Do we have enough refined stories in the backlog to support this goal?
• Do we have the right stories so support this goal?
• What risks do we know now that could impact our ability to reach this goal?

The Scrum Master helps the teams to understand and appreciate the impirical nature of Scrum. By encouraging the inspection of everything done, the team will learn to ask these questions on their own. 

Thank you to all who responded to my query. It's given me ways to think about how a Scrum Master fits in to create a Sprint goal. Beyond the theory, the open ended question approach and examples have made it clearer. 

As Scrum Master, I have contributed to the creation of Sprint Goals by asking questions such as:

• Is this goal delivering value that is needed?
• Do we have enough refined stories in the backlog to support this goal?
• Do we have the right stories so support this goal?
• What risks do we know now that could impact our ability to reach this goal?

Those are all good examples. Some others that I've asked:

• Does this goal provide enough flexibility if plan A turns out not to be the right way?
• Does this goal provide the right transparency about what the team is working towards?
• Do you want to focus this goal around an outcome? (e.g. customer feedback, or data)
• Does this goal support early or continuous delivery of value within the sprint?

I've also (sometimes) given specific feedback on a Sprint Goal if I've felt it's problematic, or could be improved. For instance if it's written in a way that stakeholders will not understand.

One of the most impactful things I can do around the Sprint Goal is to trigger discussions that allow problems to emerge. For example, if the team struggles to write a coherent Sprint Goal around the many things that it plans to work on. I've helped teams realize that this can be a symptom of a lack of focus, so that actions could be taken (immediately or later) to address it.

In my current company, in the above situation, I've even encouraged teams to have playfully written Sprint Goals like "finish off the odds and ends", or "do lots of things", because in our company culture that would not cause problems within the sprint, and I knew it would be discussed at the Sprint Review.

There can also be value in having the team write down the rationale behind setting a certain goal, as it can be a useful input for continuous improvement (e.g. a discussion point for the Sprint Retrospective).

But it's important to consider that despite all of these ways a Scrum Master can contribute to setting the Sprint Goal, sometimes it is better if they keep quiet. I try only to contribute to the discussion when it helps the team grow or learn. Sometimes that's better achieved by allowing them to try their own way, even if it turns out to be unsuccessful.