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

Last post 03:32 pm June 29, 2020
by Sumit Singh Anand
11 replies
Author
Messages
01:04 pm July 30, 2018

Sprint Goal is achieved by implementation of Sprint Backlog but not the Product Backlog right?  Why Scrum Guide says that by implementing Product Backlog sprint goal is met when it is Spring Backlog?

Can any one please clarify? Thanks in advance.

06:43 pm July 30, 2018

“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”

08:02 am September 26, 2019

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.

04:14 pm September 26, 2019

 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. 

05:15 pm September 26, 2019

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.

 

05:19 pm September 26, 2019

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?

08:30 am September 30, 2019

@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!

01:59 pm September 30, 2019

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.

09:02 pm September 30, 2019

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

07:22 pm June 27, 2020

@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

07:04 am June 28, 2020

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 

10:41 am June 28, 2020

Thanks Ian!!! :)