Skip to main content

Stretch Goals: good or bad?

Last post 09:58 am May 10, 2020 by Anand Pandey
9 replies
03:08 pm March 29, 2013

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?


11:33 am March 31, 2013

Is the "stretch goal" concept a part of SAFe? Do you have a reference/link for that?


12:38 pm March 31, 2013

03:12 pm March 31, 2013

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


07:14 pm March 31, 2013

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.


07:48 pm March 31, 2013



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.


12:43 am April 1, 2013

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.


08:02 am April 12, 2013

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.


10:46 am September 4, 2013

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!


09:58 am May 10, 2020

The desire to include optional requirements may be for various reasons, and we need to understand that within its context. One of the prominent I could think of is maximizing utilization of 'resources'.

As there are too many work items, we are:

  • encouraging Dev Team to multi-task, i.e. focus on too many things
  • discouraging transparency mid-sprint on available capacity with PO and discuss on the same in Sprint Retro, as there is always something to pick up
  • not being open to discuss our impediments and swarm to remove the impediment toward flow, as there is always something to pick up
  • encouraging individual contribution and discouraging collaboration, .i.e. each owning a work item toward the end
  • discouraging commitment as a team knows it is optional anyway

Scrum Master should coach the Scrum Team if they are going down this path.


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. For privacy concerns, we cannot allow you to post email addresses. 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.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.