Scrum Guid Says: Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog.

“The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal”

I also have this question. I do not understand this sentence, so I cannot make a good interpretation out of it.

@Ian, given your answer, shouldn't the sentence be:

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of the Product Backlog items selected for the Sprint.

However, if we consider this new the sentence, the word "can" may also be misleading. As more is learned throughout the Sprint, the Product Backlog items initially selected for the Sprint may not be the ones that will make the Scrum Team able to achieve the Sprint Goal. So, I would like to pitch for "is likely to" as replacement for "can". Therefore, the sentence would become:

The Sprint Goal is an objective set for the Sprint that is likely to be met through the implementation of the Product Backlog items selected for the Sprint.

I would like to know your thoughts on this.

 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. The entire Scrum Team collaborates on understanding the work of the Sprint.

There is further elaboration within the Scrum Guide regarding implementing PBI's and not the entire Product Backlog. I don't know if this is a common misinterpretation or if it's practitioners who have a similar understanding debating semantics. 

I'd agree with you that adding the word items as you mentioned above could likely eliminate any misinterpretations. 

Think a bit about it's execution for Sprint Planning. I like to use Direction, Demo and Capacity when I explain Sprint Goals. I'm sure there is room for improvement, but I feel like it's had positive results so far. Would love feedback as well as offering this advice up to Venu.

Direction:

You would be setting the Sprint Goal at the beginning of Sprint Planning, and by doing so, you create the ability to select the appropriate Product Backlog Items to go into the Sprint. You use the Goal to set the direction of the scope for the Sprint's Potentially Releasable Increment.

Demo:

Select the required PBI's needed to achieve the Goal. At the Sprint Review the team will Demo the Sprint Goal (state of the system and not explicitly the individual stories). Will the Goal be attained if the current set of stories are completed? By completing the set of stories, are you actually delivering more into the system than expected? Adjust the Goal/Stories as needed. 

Capacity:

Once that's done, consider the capacity of the team for the Sprint load. Team would always approve an attainable workload and never one that is unreasonable. So it is appropriate to assume the Goal will be achieved by Sprint End. If insufficient capacity exists, work backwards and remove the Stories that would be completed last, and then amend the Goal to match the current Sprint Plan.

The Sprint Goal is an objective set for the Sprint that is likely to be met through the implementation of the Product Backlog items selected for the Sprint.

Should teams be constrained into agreeing their Sprint Goal only if the Product Backlog items have already been selected?

@Tony - I agree with you, semantics may be the issue here. Anyway, the sentence you mentioned from the Scrum guide is pretty explicit.

@John - I believe that you have a good structure. I would say its success depends on what fits best for each team within Scrum boundaries. However, initial inputs to craft the Sprint Goal should contain:

• [Refined] Product Backlog,
• Previous Increment
• Capacity forecast, and
• Previous Sprint velocity ('yesterday's weather').

>"The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development >Team during the Sprint, and past performance of the Development Team." - Scrum Guide

Anyways, as you said, there is always room for improvement. Maybe, one of your Scrum Team mates has identified a point of improvement, but is not speaking up. Therefore, asking the team if they enjoy the Sprint Planning meeting and whether they would change something might unlock an improvement opportunity. I suggest doing this in the end of the Sprint Planning itself or in a Sprint Retrospective.

Not withstanding, there maybe a bigger bottleneck in your process unrelated with the Sprint Planning. So, I would focus on identifying it first. Remember, you can only go as fast as the slowest part of your process.

@Ian - Indeed, they should not, and that makes my rearranged sentence wrong. The Product Backlog items selected for the Sprint should be based on the Sprint Goal, and not the other way around. The Sprint Goal could be adjusted to meet the Development Team's understanding of work that can be done during the Sprint. Correct?

Thank you all for the valuable insights!

The Product Backlog items selected for the Sprint should be based on the Sprint Goal, and not the other way around.

Correct. The PBIs on the Sprint Backlog constitute part of the forecast of work needed to achieve the Sprint Goal. That forecast, including any selected PBIs, ought to be inspected and adapted as necessary.

The Sprint Goal could be adjusted to meet the Development Team's understanding of work that can be done during the Sprint. Correct?

The purpose of a Sprint is to meet a Sprint Goal by providing a suitable increment of work that is of release quality. The Sprint Goal can be evolved during Sprint Planning but once agreed, it is immutable. The Sprint Goal is a commitment and anchor point around which work in the Sprint Backlog may flex.

Hi Venu,

First, a clarification that the Product Backlog Items (PBIs) are contained within the Sprint Backlog (SB) along with the Sprint Backlog Items (SBIs).  It sounded like there might be some confusion around that.

The purpose of the Sprint Goal is to give meaning to the Development Team (DT) as to why they are working on the increment, to increase engagement and buy-in.  It also makes more clear that the team is not committing to completing the PBIs, only committing to completing the Sprint Goal.  So the Goal is non-negotiable but the scope to which the DT realizes the goal is negotiable.  So, say 4 PBIs are brought into the SB but only 3 are completed to the DOD.  In this case, the team was still successful in realizing the Sprint Goal but the scope to which they realized it was a little less than estimated.

Hope that helps,

Katherine

@Ian - I understand and agree with your statement that Sprint Backlog is a set of Product backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.

So will the below statement also hold true?

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Sprint Backlog

Yes, because the Sprint Backlog will be inspected and adapted by the Development Team to better meet the Sprint Goal.

The Sprint Goal can be any coherent thing which gives team members a reason to work together during the Sprint 

Thanks Ian!!! :)

Question about this statement, 

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Sprint Backlog

Does it mean “all” sprint backlog items? Or the goal could be met with “certain” Sprint backlog items? 

 

Since we are forecasting and we want to keep the team motivated to fulfil the goal and self organise would it make sense to have a Sprint goal that would summarise certain most important Sprint backlog items to be shown in a sprint review or for the PO, but leave a buffer of items (not a big one) not included in the goal so  if they are not finished by the end of the sprint, this would not be interpreted as a failure to reach the goal of the sprint? 

 

As stated this is a forecast so it can happen that not always all selected Sprint backlog items will be finished and if the goals are to tight to all sprint backlog items and the full capacity of the team for the sprint, this could lead to burn out, frustration if that the goal will not be met.

How do you approach this? 

Thanks in advance! 

In other words a practical example: 

Average velocity of 3 last sprints: 40 points 

We assign 40 points of use user stories (sprint backlog items) to the sprint backlog but our Sprint goal will be defined and accomplished when we make “done certain user stories” which sum 30 points. For example with those 30 points we complete a feature up to certain level.

These user stories of 30 points will give us a goal with clear and shared objectives that improves collaboration and self organisation. Then the remaining 10 points would be additional user stories that can add up to the feature but if not finished does not mean a goal failure. In this way I would find a better correlation between setting goals to accomplish and “forecasting”.

 

Does it mean “all” sprint backlog items? Or the goal could be met with “certain” Sprint backlog items? 

The Developers ought to inspect and adapt the Sprint Backlog, throughout the Sprint, so their Sprint Goal commitment can be better met. At any given time the Sprint Backlog should reflect the work that is genuinely thought to remain. If the Sprint Backlog is updated in a timely way, then all work on it could be completed.

There's nothing to stop a team from including scope contingency, during Sprint Planning, along the lines you suggest. Not all of the work planned for that Sprint has to be essential for the Sprint Goal to be met, and the inclusion of such contingency may improve the chances of successfully achieving it.