Forums

By posting to our forums you are agreeing to the Forum terms of use.
Stretch Goals: good or bad?
Last Post 04 Sep 2013 09:46 AM by Colin Hamilton. 8 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Ian Mitchell
Advanced Member
Advanced Member
Posts:575
Ian Mitchell

--
29 Mar 2013 02:08 PM
    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:212
    Charles Bradley

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

    --
    31 Mar 2013 11:38 AM
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    31 Mar 2013 02:12 PM
    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 06: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:212
    Charles Bradley

    --
    31 Mar 2013 06: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
    New Member
    New Member
    Posts:81
    Sanjay Saini

    --
    31 Mar 2013 11: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 07: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 09: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