Some teams use something called stretch goals or stretch stories to highlight product backlog products they will accomplish if they finish their sprint commitments early. Stretch goals are frequently used as a way to satisfy stakeholders without fully committing to the work. In some ways, it’s more real to call it out as a “stretch goal” than saying we didn’t include it in sprint A, but it’s the highest priority product in the product backlog. We think it should be up to the team whether they use stretch goals, but we would caution against using it as a tool to keep stakeholders at bay. We want to be realistic of what we can take and the more honest we can be with ourselves and our stakeholders, the better off we’ll be.
Just a Little Further?
Deciding to have a stretch goal is a decision that should be made by the team, not the Scrum Master or product owner. Only the team can know if having a stretch goal will really help or not. Some people might not do so well with the force of extra goals. They will think of the stretch goal as required and will not stop until they have completed the goal to their huge standards. This can be an unhealthy outlook and is not necessarily estimable, but there are people who operate like this. These types of people will probably not thrive under stretch goals, and therefore the team should elect to avoid them.
Other people have the ability to see a stretch goal as an added tip, and if they get to it, that is great. But if not, everything will still be okay. In a collection of people like this, stretch goals will likely meet their calculated purpose of giving the team a chance to score an “A+.” Stretch goals can be great additions to the workload, but it all depends on the team how productive they will prove to be.
Stretch Goals Assigned by Outsiders
- The worst uttermost of this type of stretch goal is also the most common! This is the fixed-scope-fixed-date project deadline. In this type of stretch goal, the project team, doing Scrum or not, is forced to work backwards from the deadline to figure out how to get the work done. If the team can’t figure this out, managers often say things like “re-estimate” or “just get it done.”
- Anecdotal experience with this sort of thing is simple: quality suffers or confirm able suffers. We once worked with three other people on a mission critical project to help two banks with their combination. There was a regulatory deadline for completing the combination of the two existing systems for things like trading, etc. Fixed-scope-fixed-date. Coffee and sleepless nights were our solution since we tried not to sacrifice quality. We actually ended up working in my home for the last few 24-hour stretches so that we would have entry to a shower. Do it to say, there’s no way we could have support that pace. It’s anti-Agile.
- A quick search for opinions and ideas about stretch goals makes it very clear that there is no commonly agreed “correct” answer. However, from an Agile view stretch goals assigned by outsiders are clearly against the principles of the Agile Manifesto.
Stretch Goals Set by the Scrum Team
- Some teams prefer to leave many of excess capacity in each sprint, may be so there is time for emergent needs or experimentation. Other teams prefer to fill the sprint to the best of their ability to predict their capacity.
- Still other teams like to take on a “stretch goal” each sprint, which is kind of a product backlog product that is not quite in the sprint, but is one the team hopes to complete if the sprint goes well. This is one of those things that need to be left entirely up to the team. It should not be up to the product owner or the Scrum Master, but up to the team. Some teams do extremely well with a stretch goal. Other teams do not. It really depends on how the team views the stretch goal.
- For example, I feel stretch goals are like a compress weight. I feel like I need to complete them. When I set a goal, I almost always achieve it. I have a hard time differentiate between what I call a “normal goal” and stretch goal. I don’t think this is good, but it’s who I am. But, I’m not the only one who does this.
- If a team included me and may be a couple of others like me, we would probably not do well with a stretch goal. The stretch goal would likely be in our minds and perhaps even affect our ability to finish all of the main work of the sprint.
- Other people–those unlike me–have what I’ll call a more mature view toward stretch goals. They can look at it as it’s calculated. They can think, “OK, great if we get to it but no big deal if not.” Teams comprising mostly people like that will probably do quite well with a stretch goal. So: Should your team have a stretch goal in their sprints? This really has to be up to the group. Unless I’m on the team. Then the answer is no.
Stretch goals destroy trust within the team.
Think about that. When a team fails to meet its own stretch goal, team members will start to look for someone to guilt. People look for explanations, for stories. The team will create its own story about why a stretch goal was missed. If it happens over and over, that story will start to become doubt about the team’s own capacity either by pin-pointing an individual or in a form team sense.
Trust and Agility
The importance of trust cannot be over-stated. In order for individuals to work effectively together, they must trust each other. How much trust? Well, the Agile Manifesto directly addresses trust: Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
If the team is consistently reaching completion before sprints end, then the team has an opportunity to figure out an improvement.