Sprint Goal update during the Sprint

As I explain it to the teams, the sprint goal is the purpose of the increment. The burning torch to guide the team and to focus on. It describes the value deliverd by the increment. All PBI's in the sprint, combined into one increment, are all there because of the sprint goal, they all contribute to the purpose, to the combined value.

In general, the only change to the sprint goal could be clarification. Once the team learns more, you can strengthen the goal and make it more clear. That is positive change, and should be welcome.

Looking at this, totally changing it after the sprint starts is very much undesired. Because inheritly changing the goal menas changing the PBI's, since they (might) no longer contribute to the "old" purpose or value.

Also, the team commits to achieving this goal. This commitment is therefore not only abandoned, it could be seen as a slap in the face for the team as well.

My first guess always is; if you feel te urge to change the sprint goal, probably the sprint goal was not a good or well stated goal to begin with.

Scope can chnage and be re-negotiated, but this does not mean the goal chnages. Only the work done to achieve the goal is changed in this process. As an example (just an example), if your goal it provide a Product Detail Page (PDP) for a webshop, having realtime stock information is a feature which can be (re)negotiated to be out of scope if it proves technically very hard to achieve, while still providing the PDP goal.

 

Does this help?

Can we change the Sprint Goal during the Sprint ?

Let's consider the motive for doing so. Would you change a Sprint Goal if it still made sense given the circumstances?

Thank you very much both Xander and Ian.

Scum guide fascinates me because it challenges us to read between the lines… and here is where we make Scrum our understanding.

So, my philosophical question about the possibility to change the Sprint goal during the Sprint should include at least these considerations:

• Sprint Goal provides guidance to the Development Team on why it is building the increment (keep the Sprint Goal in mind);
• Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint;
• During the Sprint  we running in inspection and adaptation process, but no changes are made that would endanger the Sprint Goal;
• During the Sprint quality goals do not decrease;
• During the Sprint scope renegotiation between the PO and the DT is allowed;
• A Sprint would be cancelled if the Sprint Goal becomes obsolete.

I'm not English native speaker, but the word *change*  applied to this context it's seems to make Scum Goal different.

So, definitively we can't change the Sprint Goal during the Sprint. 

By the way, you can clarify the Sprint Goal during the Sprint as you need to have a big burning torch to guide the team and to focus on.

IMHO We can not find in any part the Scrum Guide straight forward sentence that once Sprint Goal is created / set then it is done and fixed "in stone". In fact, that habit might be even against Inspect and Adapt approach. Not to mention one from twelve Agile Manifesto principles:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

or even one of its values:

Responding to change over following a plan

You have summarized above among others only a part about "scope renegotiation between PO and DT", but what about other parts of it mentioned in Scrum Guide?

Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned

We can ask, do the Sprint Goal is part of the scope or not? As it may depend on a lot of things, in my opinion it is part of the scope of the Sprint, so maybe therefore it can also be clarified and re-negotiated as more is learned?



I would also ask ourselves, does the changes that we want to perform to the Sprint Goal endanger it? If no, then is it still the same reason why we're building this increment / running this sprint, but only it is now more refined and better to understand? If yes, then why we should hesitate with changing it?



If we answer on above or similar questions differently, then we most likely are in the "Sprint Goal becomes obsolete" scenario, and therefore we should rather cancel current Sprint according to the Scrum Guide.



Just stay reasonable when you approach to this topic and consider what will happen if you change (even entirely) the current version of the Sprint Goal, and what will happen if you won't do it?

Thanks Piotr. Your clarifications are very interesting. I agree with them.

In my previous entry in this topic, basically I said that you can't change the Sprint Goal but you can clarify it. So an update is quite possible but not too much that it gets the Sprint obsolete. I think we all agree on this. 

About this topic, it is really good dive into the Scrum.org resources, blog and community looking for several tips about how define the Sprint Goal. There are a lot of literature about it that is pretty useful. I recommend it. For example, focus on user and business, make the Sprint goal visible, talk about the progress towards the Sprint Goal in the Daily Scrum, be carefully with define Sprint Goal too big, etc.. 

Moreover, can help searching for real examples or considering the Roman Pichler Sprint Goal template based on goal, method and metrics.

I do not agree with Piotr. The Scrum guide clearly states 

1.) that no changes are made during the sprint that would endanger the Sprint Goal (Page 7)

2.) If a Sprint is too long, it may endanger the Sprint Goal

3.) A Sprint could even be cancelled if the Sprint Goal becomes obsolete. 

So how are can we understand the change of something and becoming obsolete of something as being congurent?

In my understanding if something changes, the something the something was before is now something else. If this something is now something entirely different the old meaning of something is obsolete and superseeded by the new meaning of something. Thus the entire thing is obsolete, if we think that its characteristics accurately define its essence. So if the Sprint Goal is accuartely describing the essence of the value delivered to the customer and now the value for the customer is changing and thus the old value for the customer has become obsolete, we can derive that the whole Sprint Goal has become obsolete, by the very fact of the change of its outer circumstances, namely the characteristics of its value.

From this it follows that a change to a Sprint Goal means that it has become obsolete and the PO could see the need to cancel the Sprint.

Hello, 

I am interested in this topic because I had just that kind of situation with the team. I as well understand that sprint goal normally shouldn't been change. But the thing is - the situation in the middle of the sprint drastically changed and from this new information we were missing during the sprint planning - the main focus on team should be changed definitely. It's not the question of formulation it is just completely other goal. Like - not focus on chopping berries, but on finding the mamut. As we are in Agile as well agility and lightness in making change is essential as well. So option 1) would be to not change the goal technically, but still the 2.nd part of the sprint to focus on the other thing (mamut my example), at the end of the sprint define goal as not achieved - with explanation - change of priorities, but the fact is - team still focuses on something else - not official, but unofficial sprint goal - so I am thinking if it does make sence to technically not change it? From business perspective this change of team's focus in the middle of the sprint is mandatory at this case. Thank you in advance for any ideas on this one.

If the original Sprint Goal is no longer valid, why not cancel the Sprint and immediately start a new one with the new found information?  That provides better visibility into what your team is working on and how you use the Sprint Goal as the commitment for the Sprint.