Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Changing sprint scope and goal
Last Post 22 Mar 2014 02:24 AM by Ian Mitchell. 10 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Informative
Garrett Olson
New Member
New Member
Posts:5
Garrett Olson

--
16 Mar 2014 01:12 PM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1493
    Ian Mitchell

    --
    16 Mar 2014 05:11 PM
    > 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.


    Garrett Olson
    New Member
    New Member
    Posts:5
    Garrett Olson

    --
    18 Mar 2014 06:32 PM
    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?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1493
    Ian Mitchell

    --
    18 Mar 2014 07:42 PM
    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.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig  Harsch

    --
    19 Mar 2014 05:55 AM

    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
    Garrett Olson
    New Member
    New Member
    Posts:5
    Garrett Olson

    --
    19 Mar 2014 10:48 AM
    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?
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig  Harsch

    --
    19 Mar 2014 11:20 AM
    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.
    Fredrik Vestin
    New Member
    New Member
    Posts:68
    Fredrik Vestin

    --
    19 Mar 2014 02:27 PM
    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.
    Bartosz Janowski
    New Member
    New Member
    Posts:20
    Bartosz Janowski

    --
    21 Mar 2014 03:48 PM

    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
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1493
    Ian Mitchell

    --
    21 Mar 2014 04:37 PM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1493
    Ian Mitchell

    --
    22 Mar 2014 02:24 AM
    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.
    You are not authorized to post a reply.


    Feedback