Should Scrum Teams Include a Stretch Goal In Their Sprints?

Should Scrum Teams Include a Stretch Goal In Their Sprints?

April 16, 2020 0 By Bhargavi V
Share on Socialmedia


Scrum 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 about 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 backward 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 confirmable 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 solutions 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 the 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, maybe 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 compressed 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 a 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 maybe 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 doubtful about the team’s own capacity either by pinpointing an individual or in a form team sense.

Trust and Agility

The importance of trust cannot be overstated. 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.

For more Blogs:

Aleph Technologies is a premier IT training and staffing group with state-of-the-art facilities based in Dallas, Texas. Aleph Technologies specializes in providing hands-on classroom-based and onsite IT certification training courses taught by expert instructors with practical industry experience. Classes span focuses on Business Analysis, Health Insurance & Systems Domain, IT Project Management, and IT Services with emphasis on Certified SCRUM Master, Scaled Agile Certifications in Dallas, and leadership roles in Agile development. Since 2000, over 3000-course participants from more than 100 organizations across the globe have enhanced their skills through intensive, applicable exercises and education. We guide you through your Agile Transformation