Skip to main content
Back
X
Back

Scrum Forum

Changing sprint scope and goal

Last post 04:46 am February 11, 2017
by Rahul Choudhary
17 replies
Author
Messages
02:12 pm March 16, 2014

Hi all, after reading the Scrum Guide and Scrum and XP from the Trenches, I'm confused about a few things regarding the sprint goal and reducing scope.

Here's a scenario that our team recently experienced: midway through the sprint, one of our user stories is taking longer than expected to complete, usually due to a large number of bugs found that require fixes. Our burn down is starts to veer off course indicating we won't be able to reach our sprint goal, so we reduce the sprint scope by pulling the lowest-priority user story from the bottom of our sprint backlog. Does this reduction in scope come with a re-working of the sprint goal/commitment? Our sprint goal is typically, "Finish all the user stories in the sprint so they are releasable." If we don't rework that goal when the sprint scope is reduced, would it automatically be a failed sprint? Management is tracking 'failed' and 'successful' sprints (sadly), so I'm trying to clarify exactly what we can change and still have a successful sprint.

06:11 pm March 16, 2014

> 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.

07:32 pm March 18, 2014

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?

08:42 pm March 18, 2014

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.

06:55 am March 19, 2014

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

11:48 am March 19, 2014

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?

12:20 pm March 19, 2014

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.

03:27 pm March 19, 2014

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.

04:48 pm March 21, 2014

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

05:37 pm March 21, 2014

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.

03:24 am March 22, 2014

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.

05:22 pm January 3, 2017

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.

05:39 pm January 5, 2017

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.

03:13 pm February 9, 2017

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.

10:14 pm February 9, 2017

> 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.

04:31 am February 10, 2017

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.

08:41 pm February 10, 2017

> 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.

04:46 am February 11, 2017

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