Sprint Goal

"I assume it doesn't mean that the functionality can be changed."

If the functionality expected was deemed to be not contributing value towards the Sprint Goal, midway through the Sprint for example, then wouldn't you want it to be changed?

Very well said Alex. 

It is my understanding that this means that if the team comes up with a completely different way of achieving the Sprint Goal, they are allowed to do whatever they need to do.  So, for instance, let's say a team takes on 7 PBI's in a sprint, of which 3 are required to achieve the Sprint Goal (note that your Sprint Goal should almost never be equivalent to all the work in your Sprint Forecast, should nearly always be much less than that).

Then, halfway through the sprint, the Scrum Team(and/or Dev Team) figures out a different way of achieving the SG, that invalidates one or more of the 3 PBI's originally intended to achieve the SG.  The team may work with the PO to re-arrange said PBI's and Sprint Backlog to still achieve the SG.  Also, by setting your Sprint Goal to be less than the entire Sprint Forecast, this gives the team some flexibility about what *amount* of functionality they complete in the Sprint.

The Sprint Goal serves several purposes:

1. It gives the Scrum Team focus around the business goal trying to be achieved.  That is the #1 priority for the sprint.
2. It reminds the Scrum Team that regardless of our Sprint Backlog and selected PBI's, those artifacts, while during the Sprint, are highly changeable and completely secondary to achieving the SG.  
3. If done well (work to achieve Sprint Goal << work to achieve Sprint Forecast), the team is not tied into a "fixed scope/fixed date" mentality (which is waterfall thinking anyway).  Scrum thinking on this topic is that software development is inherently complex, even within a 2 week (or other length) Sprint, there is complexity and unknowns -- as such, we don't ever want to create a contract around the *amount* of the functionality delivered.  Instead, we contract to achieving the Sprint Goal and providing transparency rapidly. (this point has many ties to Empirical Process Control) [one might also consider the Sprint Goal as a way to create an uncertainty buffer inside the sprint -- the gap between work needed to achieve goal and work needed to achieve the Sprint Forecast is essentially the uncertainty buffer]

Could someone help me understand the meaning of this sentence in The Scrum Guide under Sprint Goal: "The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint."

Think of the Sprint Backlog as a forecast of the work the Development Team reckons is needed for them to meet the Sprint Goal. While Development Team members may reasonably commit to achieving the goals of the team, they would be unlikely to commit to a forecast. Forecasts are expected to change, and so the functionality planned into the Sprint Backlog may also be expected to change. Without that change, meeting the Sprint Goal will become harder in evolving conditions and the light of experience. The Daily Scrum is an opportunity for the Development Team to inspect and adapt their progress in that regard.

Thank you everyone for these very helpful answers!

Ian,

> Think of the Sprint Backlog as a forecast of the work the Development Team reckons is needed for them to meet the Sprint Goal

I'm a little uncomfortable with this language, because it implies amount of work to meet Sprint Goal == amount of work to meet Sprint forecast.  Having said that, the Scrum Guide has similar language that ALSO makes me uncomfortable:

"The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal" [SGuide]

While the SG(Sprint Goal) sentence is true, it also **implies** (esp to the casual practitioner/reader) the amount of work to meet Sprint Goal == amount of work to meet Sprint forecast, and this is not usually the case.  Otherwise the Sprint Goal would likely either a) rarely be met due the inherent uncertainty in software dev -- which means Sprints would have to often be cancelled due to the SG being endangered or b) the Sprint Goal would not really allow for much if any flexibility about the functionality delivered as it promises to do in the Scrum Guide.

"The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint."

I contend that by suggesting/implying, or often deciding that the amount of SG work == amount of Sprint Backlog work == amount of Sprint Forecast, we are creating a fixed scope/fixed date waterfall trap.  The idea behind the Sprint Goal of creating a shared goal for the Dev Team to rally around is great, but I'm not sure it's great if it strongly implies waterfall thinking.

So, my problem isn't so much with Ian's language, as it is with the Scrum Guide itself.  :-)

I can't edit my above comment, so I will just append to it by saying..

Ian, your thoughts on this?

I'm a little uncomfortable with this language, because it implies amount of work to meet Sprint Goal == amount of work to meet Sprint forecast

I don't believe that the implication is actually there, because a Sprint forecast does not exist to be met. A goal exists to be met, while a forecast is a plan for doing so which is transient in nature and subject to ongoing revision.

Ian,

I agree that the forecast does not exist to be "met", but I think the reading of the Scrum Guide by the casual reader will give them that impression, especially with statements like the above and these:

" However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint." -- Scrum Guide 

"The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog." -- Scrum Guide  [notice it doesn't say "plan for achieving the Sprint Goal", and contrast this stmt about the Sprint Backlog as it relates all the PBI's selected vs. just the ones that support the Sprint Goal as mentioned in the quote above..]

Anyway, even trainers disagree sometimes on fine points! 

I still think the guide is vague on these points.  Regardless, we answered the main question posted by the OP above anyway.

@Ian and Charles,

I would like go to further with this adaptability of the workload in the Sprint VS the Goal.

I'm not very confortable with the idea of having most of the PBI related to the Sprint Goal and a few "bonus" PBI not related to the Sprint Goal. Sure, it give some slack, but why should someone worry with work not related to a goal ? 

And I'm not very confortable with the idea of having every PBI related to the Sprint Goal, because the Sprint Goal will to  often be endangered. I like the concept of having a creative Dev Team that can find some work around to meet the Sprint Goal by simplifying some PBI, but so :

1- why not having simplifying PBI before ?

2-experience shows it is very rare the find simplification "on the fly"

So my question is how can the Dev Team really preserve the Sprint Goal when 1 or 2 PBIs are not going very well and the PBIs have already been simplified before Sprint Planning Meeting ?

I'm not very confortable with the idea of having most of the PBI related to the Sprint Goal and a few "bonus" PBI not related to the Sprint Goal. Sure, it give some slack, but why should someone worry with work not related to a goal ? 

The Sprint Goal does not have to be the *only* goal which is observed by a team. It's possible that other goals may be agreed and committed to by team members as well. An example might be the so-called "stretch goals" you occasionally find teams planning into Sprints. While I disapprove of the "stretch goal" term, I appreciate the intent to make ancillary work transparent and to provide scope flex via work which can potentially be removed. The commitment framed by a team may to be to perform any "stretch" work only if the Sprint Goal is achieved. What matters is that any other goals do not actually put the Sprint Goal at risk.

And I'm not very confortable with the idea of having every PBI related to the Sprint Goal, because the Sprint Goal will to  often be endangered.

This risk might be managed by using the stretch goal approach, or perhaps by classifying Sprint Backlog Items as Must/Should/Could in relation to the Sprint Goal, or by otherwise estimating the relative value of each item.

I don't agree with the term 'slack', just in general.  In the USA, the term 'slack' has multiple widely different definitions, and the term 'slacker' has a strong negative connotation that is too closely related..  I much more prefer something like "buffering for the inherent uncertainty of software delivery".  (or "uncertainty buffer") 

(I also don't have a perfect term for this either -- I'm wondering if that's why they avoided trying to name such a thing in the Scrum Guide!)

SAFe implements this same thing, but uses a whole different set of terminology/practice.  Either way, having an uncertainty buffer, even inside the sprint, is highly valuable.

Hi all,

I am a bit confusing about the Sprint forecast in relation with the Sprint Goal.

Charles Bradley commented that the Sprint Goal should almost never be equivalent to all the work in your Sprint Forecast, so, is the Sprint goal only a forecast?

Thank you!

Regards,

Raúl.

is the Sprint goal only a forecast?

The Scrum Guide says: "People personally commit to achieving the goals of the Scrum Team."

Do you understand the importance of having a forecast of work which can be inspected and adapted until the Sprint Goal is met?

Sometimes teams find themselves in a situation where they have a clear main focus for the duration of a sprint, and a few additional items that are required/desired/valuable for some other reason. The team might consider it unhelpful/distracting to craft a Sprint Goal around such items, but still decide to complete that work.

Usually when teams struggle with this apparent conflict between focusing on a Sprint Goal and having other unrelated items that they plan to complete within the sprint, I ask them to imagine that there will be a newsletter published about the sprint, and to consider what the desired headline would be. That headline can often be the basis of the Sprint Goal.

Perhaps a Sprint Goal disregards the most valuable thing, or the thing that requires most work; but ideally supports focus, empiricism, and self-organization.

Being unable to focus on a specific Sprint Goal may be a symptom of some dysfunction within the team or organization. If setting the Sprint Goal is difficult or doesn't appear to help the team, it can be beneficial for the Scrum Team to explore why.

Totally makes sense Simon!