Changing sprint scope and goal

> Our sprint goal is typically, "Finish all the user
> stories in the sprint so they are releasable."

As a Sprint Goal that is worse than useless. It says nothing about the business value the Product Owner seeks for that increment and has negotiated with the Development Team. All it does is to set the team up to fail, by definition, if even one story is missed.

> Management is tracking 'failed' and 'successful' sprints (sadly)

Actually that's a perfectly reasonable thing for stakeholders to track. What's unfortunate is that, in this case, they will not be able to gauge success or failure in terms of business value. There is no clear rationale to any of the increments being worked on.

Coherent and valuable Sprint Goals are essential to Scrum. They define the purpose of the increment. Stories can and should flex if necessary so the increment can be delivered. Sprints are meaningless without valuable increments and that value is expressed in their goals.

Ian, thanks for the insight. Our current sprint started yesterday, and we created some concrete sprint goals which are now prominently displayed on our wall. I have few more questions about the sprint goal, perhaps you would shine some light on:

*In our current sprint, we have four sprint goals corresponding to four pieces of functionality we plan on completing by the end of the sprint. In Scrum today, our PM announced that one of those goals, implementing a new API integration with an outside company, is likely not going to happen due to a change of direction. When changes of business direction like this happen mid-sprint, do we simply drop it as a goal or does the sprint fail?

*If the sprint goals are all completed ahead of time, can the team add additional goal to keep the team productive?

Each Sprint should have one goal. It represents the totality of the value that should be delivered in this increment rather than any other. Why are these stories being chosen for this particular increment? Where is the business value in binding them together?

In other words you wouldn't have multiple goals in a Sprint...but you would expect multiple stories to contribute to a goal.

Posted By golson on 18 Mar 2014 07:32 PM

*In our current sprint, we have four sprint goals corresponding to four pieces of functionality we plan on completing by the end of the sprint. In Scrum today, our PM announced that one of those goals, implementing a new API integration with an outside company, is likely not going to happen due to a change of direction. When changes of business direction like this happen mid-sprint, do we simply drop it as a goal or does the sprint fail?

As Ian suggests, one sprint goal helps you to focus. Four goals will not fulfill this purpose.
Now what to do? Basically it's up to the Product Owner, if he sees value in continuing with the sprint although the goal will only be fulfilled partially. For the next sprint he should select only one goal, not only because then this decision is easier ;)

*If the sprint goals are all completed ahead of time, can the team add additional goal to keep the team productive?

If the sprint goal (only one) is completed ahead of time, the team can do whatever they want. This includes adding additional PBIs to the Sprint Backlog. However you should not add another goal. What happens if they don't reach it? The sprint is perceived as failed, although the team reached its (original) goal. You should not punish a team for reaching a goal by adding another goal for the same deadline.
Best, Ludwig

I'm starting to understand the sprint goal much more clearly now, but that still leaves me wondering how we'll settle on *one sprint goal. A lot of work we do is spread across multiple business areas that are often unrelated in functionality. For example, in a sprint, the business priority may be to develop a small tool for the software, fix some few production bugs, and implement two different API integrations. These objectives are largely unrelated, but each is too small to make up a single sprint, and ultimately, we need all of these functionalities implemented. Thus explains the four goal: to complete each of the four small bits of functionality. Am I missing something here?

Hi golson,
I know exactly what you mean, because I have experienced the same situation. In an ideal world, you have a vision guiding you, and you decompose this vision to release goals and sprint goals.
But in reality, you can have a Product Owner who just wants "A little bit from this, a little bit from that". Of course you can define one of those things as sprint goal, e.g. the small tool for the software. But probably some developers will be busy with the API integrations and not care about the tool at all, so the goal won't help those guys. In that case, I don't see much value in defining a goal, and I think you are still using Scrum if you omit it.
Maybe you can support the Product Owner in seeing the value of a Product vision.

Very interesting discussion and this situation is familiar to me as well. I agree with golson and Ludwig, sometimes the PO will just want little things and it may be hard to craft a sprint goal from that. If this happens all the time then that suggests that you either don't have a clear long-term goal i.e. product vision or that you're not working toward that goal.
Often there's a conflict between short- and long-term goals and it's very easy to get caught just working with short-term stuff such as customer requests but that may not get you any closer to the long term goal It is important to continuously review the product and ask yourself if you are getting closer to that and if you're getting there fast enough. If the PO feels that you're moving too slow then maybe cut short-term goals in favor of more long-term goals.

Posted By Ian Mitchell on 18 Mar 2014 08:42 PM
Each Sprint should have one goal.

I don't really understand why sprint should have only one goal? It's hard to achieve for long sprint (like for 4 weeks). The simplest case is when there is "almost-finished" US (goal) inherited for previous sprint which might be the part of the next sprint. But it's too small for the whole sprint, hence an additional goal (USs) is needed.

Such requirement looks for me quite unnatural and gives nothing.

But I would like to get your opinion.

BR,
Bartek

Each sprint should have one goal because there should be a clear purpose to each increment, i.e. a purpose which would make for a coherent release.

In other words, if the user stories in a sprint don't have a joint purpose, then there would be no rationale for combining them into a potentially releasable increment.

NB another way to look at this is to ask why work should be batched into sprints and their increments at all. If you can't come up with a unique clear and purposeful Sprint Goal for each increment, why bother working in sprints? Remember that in Lean theory you'd want to reduce batch sizes as far as possible, ideally down to single piece flow. So what value can sprints...and their associated unique Sprint Goals...possibly add?

This is an argument often made by Kanban advocates, and it is behind the use of Scrumban as a deconstructionalist remedy to the supposed "waste" inherent in Scrum. When seen in this context, the question posed about the value of sprints and Sprint Goals is a sensible one to ask. Why not just have a stream of User Stories drawn from a single backlog...each of which can be a goal in its own right? Why not reduce the "sprint" to a regular heartbeat event during which metrics are assessed and the agile process inspected and adapted?

The answer is that not all work resolves to discrete, fully qualified items that can be progressed and released in the manner of independent tickets. Business As Usual work can admittedly be like that, which is why Kanban is often chosen as a BAU service delivery model. Project work on the other hand tends to be high-risk and of unclear scope. It then makes sense to agree on a general goal to be met within a specified timebox, and to flex the Sprint Backlog items around that. This is one of the reasons why User Stories are a good fit for Scrum...they are placeholders for the necessary conversations to take place during the Sprint.

I don't see a reason of grouping unrelated business concepts in a single sprint. It depends on the context, but maybe it would be feasible to split the team into multiple teams that will work on different sprint goals. Also, "creating API" might not be the best sprint goal. What is the business value of that API? Defining sprint goal related to the business value is important because, in this case, failure to implement all components of the API will not necessary lead to failed sprint goal.

As Ian mentioned, I think without a clear sprint goal, I don't see much value in using Sprints and Scrum.

If you think about it, the Daily Scrum also wouldn't make sense there, because the 3 questions are all related to a sprint goal. If people are aiming at 4 different targets, there won't be the same inclination to swarm.

Scrumban/Kanban is a better fit where there are many goals to get in a 2 week cadence. I have experienced this exact situation recently and we decided to switch.

Hi Ian,

I am following you posts very diligently over this forum. Whatever, you have explained for Sprint Goal in this thread make sense. Having said, i still have one query over this.

For example: We are following a 2 week Sprint. We have planned a spring Goal to deliver complete integration for end to end Trade Booking. However, Due to some technical reason (impediments), the integration is not complete. Still, the work on GUI is complete & back end development activities are also completed. As, integration was the task for last 2 days in sprint. SM is not able to resolve this impediments.

Now, in this case, if Dev team approached to PO for discussing the change of this POI (story point). Whatever PO agreed with DT, in any case it will change or alter the Sprint Goal.

However page 8 if Scrum guides says

During the Sprint:
• No changes are made that would endanger the Sprint Goal;

I seek some clarity over this thin line of change in scope of Sprint back log & how it cannot always impact the Sprint Goal. As far as my understanding of SCRUM guide says, if Sprint Goal change Sprint become redundant and also changing Sprint back log is very common practice due to certain practical reasons.

What's the best technique to safeguard Sprint Goal, with out being too hard on Dev team.

> integration was the task for last 2 days in sprint. SM is not able to resolve this impediments

That's the risk of deferring integration to the end of the Sprint. It's better to manage risk throughout the sprint by integrating continually, or at least early and often at multiple discrete points.

> Now, in this case, if Dev team approached to PO for discussing the change of this POI (story point).

The Dev Team doesn't need to approach the PO at all regarding story point changes, since they are wholly responsible for their own estimates.

> Whatever PO agreed with DT, in any case it will change or alter the Sprint Goal.

No. Story point changes would not alter the Sprint Goal, nor would any discussions about the scope of work itself. In Scrum, the Sprint Goal should not change during the Sprint.

> However page 8 if Scrum guides says
>
> During the Sprint:
> • No changes are made that would endanger the Sprint Goal;
>
> I seek some clarity over this thin line of change in scope of Sprint
> back log & how it cannot always impact the Sprint Goal. As far as
> my understanding of SCRUM guide says, if Sprint Goal change
> Sprint become redundant

The Sprint Backlog is a forecast of the work that the Development Team will need to do to meet the Sprint Goal. If a change in scope would help better meet the Sprint Goal, then the forecast of the work to be done should change accordingly. If it seems that the Sprint Goal cannot be achieved at all, no matter how the plan of work is revised on the Sprint Backlog, then the Product Owner has the option to cancel the Sprint.

> and also changing Sprint back log is very common practice due to certain practical reasons.
> What's the best technique to safeguard Sprint Goal, with out being too hard on Dev team.

The Development Team wholly own the Sprint Backlog. It is theirs. Only they can change it, so the matter of "being too hard" on them will not arise if Scrum is being implemented properly.

In general, a failure to integrate an increment will mean a failure to meet the Sprint Goal, since the work done will not be in a releasable state. It is therefore usually best to sacrifice scope in favor of integration, should sacrifices need to be made during a Sprint. This might mean a reduction in the available functionality, but a carefully crafted Sprint Goal will allow for flexibility in this regard.

I think that the main takeaway for your team in this case is the need to address integration risks earlier and more often.

Thanks Ian,

It's informative and cleared my doubts. Reality is no matter how better you understand SCRUM GUIDE, There is always a deeper meaning available.

> If it seems that the Sprint Goal cannot be achieved at all, no matter how the plan of work is revised on the Sprint Backlog, then the Product Owner has the option to cancel the Sprint.

It is clear to me that , only those spring back log changes are acceptable to PO, which does not dilute the Sprint Goal or in a way only enhance the delivery of Sprint Goal to DONE increment.


> It is therefore usually best to sacrifice scope in favor of integration, should sacrifices need to be made during a Sprint. This might mean a reduction in the available functionality, but a carefully crafted Sprint Goal will allow for flexibility in this regard.

It is also clear now that, Sprint Goal is utmost priority over other detailed features.

>The Dev Team doesn't need to approach the PO at all regarding story point changes, since they are wholly responsible for their own estimates.

One last clarification on this. You mean to say, until any addition/deletion on Sprint back log is not impacting the Sprint Goal, Dev team is the in charge of all the changes( As, they own their estimates and responsible for it). However, any change or situation which can impact the Sprint Goal need to be discussed with PO. Then PO can take the call with Sprint fate.

If what ever i have stated in previous 3 lines is right. Can PO take a call to amend the Sprint Goal rather then cancel the Sprint. After all, changes Sprint Goal is still adding value to the business, rather then canceling it.

The nut , I am trying to crack is " if any SBL change impacts Sprint Goal, is Canceling Sprint is the only Option". I understand that , if we follow SCRUM 100%, this situation will not arise very often. However, for new teams following SCRUM, this situation is very much common.

> One last clarification on this. You mean to say, until any addition/deletion
> on Sprint back log is not impacting the Sprint Goal, Dev team is the in
> charge of all the changes( As, they own their estimates and responsible
> for it). However, any change or situation which can impact the Sprint Goal
> need to be discussed with PO. Then PO can take the call with Sprint fate.

Correct.

> If what ever i have stated in previous 3 lines is right. Can PO take
> a call to amend the Sprint Goal rather then cancel the Sprint. After
> all, changes Sprint Goal is still adding value to the business, rather
> then canceling it.

Strictly speaking, no. The Sprint Goal cannot be amended. However, if the Product Owner cancels the Sprint, the team may use the remainder of the time-box to deliver as much value as possible. The maximum value ought to be leveraged out of the situation. A new tactical goal for the time that is left may be framed for this purpose.

> The nut , I am trying to crack is " if any SBL change impacts Sprint Goal,
> is Canceling Sprint is the only Option". I understand that , if we follow
> SCRUM 100%, this situation will not arise very often. However, for new
> teams following SCRUM, this situation is very much common.

If the Sprint Goal is no longer viable, and the expected value cannot be delivered, then the Sprint ought to be canceled so time and resources are not wasted. It would be better to use the remaining time to achieve something which *is* viable and which provides value. Whether cancellation is justified in those terms or not is the Product Owner's decision. Applying Scrum rigorously is indeed very hard, and especially so for teams which are new to it.

Thanks Ian, It really helped a lot.Indeed,it is very hard to apply SCRUM rigorously.

Hello Ian Mitchell, 

you said 

>> It would be better to use the remaining time to achieve something which *is* viable and which provides value.

or on the scrum Guide, at the end of the section Cancelling a sprint:

" Sprint cancellation consume ressources, since everyone has to  regroup in another sprint planning to start another sprint" it meens that we have to start a new sprint when the previous one is cancelled.

can  you pls calrify ? 

If a Sprint is canceled, a Scrum Team will broadly need to do two things. Firstly they must re-plan the Sprint and try to squeeze as much product value as they can out of the work which has been done, not forgetting to put the Product Backlog in order; and secondly they must seek to understand why cancellation became necessary. They should avoid any need for Sprint cancellation in the future since it is wasteful.

Thank you Ian for the answer

Hi Ian,

I followed the whole discussion, however i have one question here. What does Sprint Failure means. Now what i wanted to say is: Scrum ever fails? Why i am asking this is suppose i have few story points let's say 20 in my sprint and by the end of the sprint i delivered 15 SPs that produced some value however 5 are still left. Why we call it as a sprint failure? Team delivered some workable functionality and those that is left can be put back in PB and PO can decide and prioritize it for the next sprint. Isn't it? Yes of course retrospective should be done as to why we didn't delivered all the SPs but we did deliver something. Waiting for your answer on this

I followed the whole discussion, however i have one question here. What does Sprint Failure means. Now what i wanted to say is: Scrum ever fails? Why i am asking this is suppose i have few story points let's say 20 in my sprint and by the end of the sprint i delivered 15 SPs that produced some value however 5 are still left. Why we call it as a sprint failure? Team delivered some workable functionality and those that is left can be put back in PB and PO can decide and prioritize it for the next sprint. Isn't it? Yes of course retrospective should be done as to why we didn't delivered all the SPs but we did deliver something. Waiting for your answer on this

I wouldn't say that constitutes a failed sprint. In my opinion a sprint fails either because the team failed to deliver a done product increment (apparently it happens more often than you'd think), or because the sprint goal wasn't met. Barring that, or a sprint cancellation as described by Ian earlier, the Sprint is successful, regardless of whether or not the team met its forecast.

Whether or not the Sprint Goal is met consitutes an absolute condition, because it should always be clear to the team whether or not they are on course to achieve it. Hence either the goal is met or it isn't. 

Nevertheless it is still possible for value to be delivered even if the Sprint Goal is not achieved. Some work may have satisfied a level of Done and be releasable. Also, if a Sprint is cancelled, the team should leverage as much value out of the work in progress as they can.

In Scrum, the word "failure" would not be used to describe such things. Rather, "failure" in Scrum would mean not implementing the framework properly, such as by compromising the roles, events, or artifacts. That's more or less the context in which the word is used in the Scrum Guide.

Just as anecdote, my last company considered any item not closed on Jira that had been on the Sprint Backlog as a failed Sprint.  A full document was written in addition to the Scrum Guide, where the term Sprint Failure was formalized. What about the Sprint Goal?  We don't use that term round here!  Unsurprisingly, teams rushed work, disguised unfinished work, or blamed others for such failed sprints.

I did a search on "changing sprint goals" and found this excellent blog, have read the posts and the applicable parts of the scrum guide, and have this situation:

We have 3 Sprint Goals this Sprint, in order of priority and our lowest priority goal will not be met, we discovered mid-way through the sprint.  Any problem with the team and PO agreeing to move this goal and the corresponding PBI's out of the current sprint?

We have 3 Sprint Goals this Sprint, in order of priority and our lowest priority goal will not be met, we discovered mid-way through the sprint.  Any problem with the team and PO agreeing to move this goal and the corresponding PBI's out of the current sprint?

There is clearly a problem regardless of whether they move it not. The problem is that the team attempts to frame multiple Sprint Goals during a Sprint, and hence team members become uncertain of their commitment.

Hi Ian,

 It is an old post but I hope it is ok if I ask a question related to cancelling a sprint when team feels they can't achieve sprint goal

>If the Sprint Goal is no longer viable, and the expected value cannot be delivered, then the Sprint ought to be canceled so time and resources are not wasted.

Scrum guide mentions that sprint could be cancelled if the sprint goal becomes obsolete. It doesn't mention inability to achieve goal as a reason to cancel the sprint.  It may be better for scrum team to continue the sprint until timebox is over and complete as much work towards sprint goal as possible, then share the reasons for not achieving the goal during review, reflect on this situation during retrospective & improve.

Please share your thoughts.

The Scrum Guide says:

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

I'd suggest that obsolescence is therefore a value-based decision. If the Product Owner -- who is accountable for product value -- believes that satisfactory value can no longer be obtained by pursuing the Sprint Goal, then he or she may deem it necessary to cancel the Sprint.

The decision facing the Product Owner is whether a continued investment in the Sprint Goal is justified. Every effort ought to be made to continue the Sprint and to provide valuable, Done work that meets the Sprint Goal commitment.

Thanks Ian 

I have followed this interesting thread and I just want to ascertain for an updated knowledge the following:  

"In the middle of a Sprint, can we adapt or update the Sprint Goal to suit if there is an impediment that has emerged which will impact the original Sprint Goal from not fully realisable in a situation where a team has two Sprint Goals"

Sprint Goal should not be more that one, however in this particular situation what is the best approach on the "Sprint Goal" adaptation? Ian mentioned lost focus in one of this tread if a Sprint Goal is more than one which is true however, practically it happens at times due to many factors. 

Some clarity is needed from the experts in the house as I am still learning. 

Hi Joseph,

Sprint Goal is singular.

"The Sprint Goal is the single objective for the Sprint" - SG

By being singular, it provides coherence and focus for the team.

In terms of...

"an impediment that has emerged which will impact the original Sprint Goal from not fully realisable"

What does "not fully realisable" mean? The objective of the Sprint can't be met? Or do they mean all PBIs won't be completed. Big difference.

"can we adapt or update the Sprint Goal"

Scope may be clarified or renegotiated so Sprint Goal objective could still be met, but Sprint Goal itself isn't changed. 

Sprint Goal is intended to remain the same throughout the Sprint, unless something comes up that renders it obsolete and no longer valuable enough to pursue. If that occurs, the Sprint Goal is abandoned and a new Sprint is initiated with a new Sprint Goal.

An impediment in reaching the Sprint Goal doesn't negate the Sprint Goal itself. As an analogy, the finish line in a race isn't moved if a runner trips during the race. The goal remains the same in both cases and it is steps taken towards achieving the goal that are adapted.

@Ryan Kent, thanks for a deeper insight.