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.

Sprint Goal
Last Post 19 Mar 2014 05:29 AM by Anja Huebler. 3 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
Franck van der Sluijs
New Member
New Member
Posts:22
Franck van der Sluijs

--
18 Mar 2014 01:24 PM
    Our sprint contains different PBI’s and bugs without relation; the only relation is that the items are for the next release of the same product. Do we need a Sprint Goal? Can the goal be a generic statement like “Implement some new features and fix some bugs”?
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    18 Mar 2014 11:25 PM
    Hi Franck,
    no you do not need a Sprint Goal in this case. It won't improve anything, because the sprint goal is supposed to provide guidance and focus. For this sprint you have to live with that.
    What you can improve for the next sprint:
    The PO should create a vision for the product.
    The PO should break down this vision into goals for releases.
    The PO should select PBIs for the next sprint which bring him a step in the direction of the goal for the next release.
    If he does a good job, it will be possible to craft a SMART sprint goal in the next sprint planning (specific, measurable, achievable, reasonable, timely).
    Best, Ludwig
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1676
    Ian Mitchell

    --
    19 Mar 2014 12:07 AM
    > the only relation is that the items are for the next release of the same product

    This suggests that there *may* be a goal for the current sprint which has simply not been articulated. It seems that there is a clear motive for this increment to be released. This implies that someone, for some reason, made the decision to aggregate these items and make them available. Presumably there are forces at work here, and the rationale behind the selection of these items might not therefore be entirely random. Perhaps promises have been made to a certain stakeholder or group of stakeholders...in which case satisfying those interests might be the goal? Try doing some root cause analysis on this and see what comes out.
    Anja Huebler
    New Member
    New Member
    Posts:3
    Anja Huebler

    --
    19 Mar 2014 05:29 AM
    Hey Franck,

    since you should aim to have a running increment with specific functionalities at the end of the sprint, you need a specific sprint goal as well.
    Your proposal tu use...

    > a generic statement like “Implement some new features and fix some bugs”?

    ...won't be a good base to work agil. You need something precise to work with. As Ludwig wrote, your outcomes have to be measurable, among other things. Otherwise you won't be able to match goals and definitions of done.
    Ask yourself e.g., how many features are the "some" you need to deliver at the end of the sprint?
    To omit the sprint goal wouldn't be very helpful. It means you would miss out the effects of scrum. The more specific you define, the better you'll be able to identify impediments. And that means, you are able to react in a specific way.

    You are not authorized to post a reply.


    Feedback