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.

Stretch Goals: good or bad?
Last Post 04 Sep 2013 05:46 AM by Colin Hamilton. 8 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Ian Mitchell
Veteran Member
Veteran Member
Posts:1687
Ian Mitchell

--
29 Mar 2013 10:08 AM
    I recently posted on this forum about "hardening sprints", a controversial feature of the Scaled Agile Framework (SAFe). Here's another one for consideration...the recognition of so-called "stretch goals". I have mixed feelings about them.

    On the one hand they are innocuous enough. Stretch goals are no different from "nice-to-have" requirements. They may or may not get delivered and build a measure of contingency into a timebox which can be put to productive use. They are also eminently tradeable for higher priority work...such as the operational support duties that plague so many "project" teams in the real world.

    On the other hand, Scrum says nothing about them, or indeed about budgeting contingency in any form. A team forecasts what it reckons it can do, and if it finishes early then more work can be brought forward out of the Product Backlog. The team members shouldn't be pushed beyond their comfort level...and seen in that light, "stretch goals" are anathema.

    For me, the one thing I definitely don't like is the term itself. I see it as pointy-haired corporate speak of the worst order. Talking about "stretch goals" turns the timeboxed delivery of Minimum Viable Product into the hallmark of a mediocre team that can't be stretched, when it is actually the defining characteristic of a truly agile one.

    Opinions?
    Charles Bradley
    Basic Member
    Basic Member
    Posts:411
    Charles Bradley

    --
    31 Mar 2013 06:33 AM
    Is the "stretch goal" concept a part of SAFe? Do you have a reference/link for that?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1687
    Ian Mitchell

    --
    31 Mar 2013 07:38 AM
    Charles Bradley
    Basic Member
    Basic Member
    Posts:411
    Charles Bradley

    --
    31 Mar 2013 10:12 AM
    Ignoring SAFe because it's not that important of a topic for me...

    Scrum doesn't really say much about "stretch goals", but you rightly point out that it can be a serious dysfunction. OTOH, if the dev team decides that they want to make stretch goals, I could see how that might possibly have value, and probably sometimes turns into a dysfunction and sometimes not.

    I definitely strongly discourage "optional requirements" if they are contained in a single PBI. If they are in separate PBI's, then I guess I'm ok with -- because that just means that they are ordered just like any other PBI. One can certainly question the wisdom of said approach, though.

    I've coached Shu level teams that wanted stretch goals -- but it was usually a short lived phenomenon, probably in part due to me discouraging that behavior and showing how it doesn't make sense (especially optional requirements within a PBI). :-)
    Brett Maytom
    New Member
    New Member
    Posts:2
    Brett Maytom

    --
    31 Mar 2013 02:14 PM
    I agree with Charles on this.

    I would simply let the team get them to forecast based on what they feel they can realistically achieve based on their current velocity. Adding in stretch goals may encourage them to reduce quality to get more done or set them up for disappointment.

    I will encourage the team to try do better than before and get more done without compromising quality. As a team starts getting to grips with the subject domain, each other it is expected to see improvement in their ability to deliver; be transparent about this. Always have groomed requirements ready for the case where the team is able to take on more work.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:411
    Charles Bradley

    --
    31 Mar 2013 02:48 PM

    Always have groomed requirements ready for the case where the team is able to take on more work.

    I encourage this too, but I just make sure the groomed requirements/PBI's do not appear anywhere where they could be confused for stretch goals.

    In our courses, we say to have 2 sprints worth of stuff beyond the current stuff well groomed anyway. I usually work with Shu level teams who never get to that in the short time frames I'm with them, but certainly 1/2 a sprint's worth in case new work is needed.
    Sanjay Saini
    Basic Member
    Basic Member
    Posts:158
    Sanjay Saini

    --
    31 Mar 2013 07:43 PM
    I feel that the term "stretch goal" may be coined by resource managers who wanted to get maximum out of their resource or by the scrum teams which are apprehensive in saying that they have some undone work in the sprint.

    If anything is just "nice to have" and is at the lowest priority and team is not fully committed/forecasting to those items which means those items can wait till next sprint so no need of keeping the stretch goals. There are chances that team members picking up the stretch items while compromising the quality of forecasted items. Team should take whatever they are comfortable with, no over-commitment.
    Stacy Cashmore
    New Member
    New Member
    Posts:2
    Stacy Cashmore

    --
    12 Apr 2013 03:02 AM
    Personally I hate the term. It was mentioned when our teams started with Scrum and something that strongly disagreed with and managed to get the PO to not mention it to the team. If the team finishes all the stories for a sprint, with good results then why should the reward be 'You should stretch yourself to do more in the next sprint".

    If the team is doing things right then velocity will increase in a sensible fashion without sacrificing either quality or making them endanger their sustainable pace. I feel it encourages working longer rather than working smarter, and will backfire in the long term.

    I would rather concentrate on what there is inside a team that is holding back acceleration rather than forcing the team to "try" and complete more work than they think is doable. This is sometimes harder to find, and may be even more difficult to solve, but will ultimately provide better payback.
    Colin Hamilton
    New Member
    New Member
    Posts:5
    Colin Hamilton

    --
    04 Sep 2013 05:46 AM
    I personally hate the term "stretch-goal".

    I'm in the middle of reading The Clean Coder, and Uncle Bob quotes Yoda a few times. "Do or do not. There is no try".

    A stretch goal is to "try". We either commit to the stories on a sprint, or we don't.

    If we find ourselves with spare capacity (perhaps because something was easier than we thought), then we will either speak with the Product Owner about taking the next item from the backlog, or working on our own engineering tools to improve future sprints.

    Adding a stretch goal supposes that the top item from the backlog won't change through the sprint, or suggests that we could really have taken on more; tried harder!

    You are not authorized to post a reply.


    Feedback