Stretch Goals: good or bad?
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.
Is the "stretch goal" concept a part of SAFe? Do you have a reference/link for that?
Here you go:
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). :-)
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.
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.
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.
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.
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!
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.