Get certified - Transform your world of work today

Close

Stretch Goals in Agile Development

21 September 2016


Applying the SMART (specific, measurable, attainable, relevant, and time-bound) principle means that a Scrum team commits to what they can deliver within the timebox of the sprint. But some teams (specifically in the Scaled Agile Framework, or SAFe) may include stretch goals or objectives in a sprint.

Stretch goals in Agile (Scrum) development allow the team to plan for a few more tasks in addition to their committed work during the sprint, so that if they finish their committed work early, they can spend their time on the additional tasks. Though the team hopes to get those additional tasks done, they are not sure they can get to them within the timebox. Hence, those additional tasks are not committed. According to Scrum principles, the team should commit only what they can do or deliver.

Below is a list of features, and the advantages and disadvantages of stretch goals or objectives.
 

Features

  • A stretch goal is not considered a committed deliverable in the sprint.
  • If the team has additional bandwidth, it can use it to complete stretch goals or objectives.
  • Research or spikes are good candidates for stretch goals or tasks.
  • Stretch goals or tasks are planned work.
  • It’s a pull mechanism used to take more work if time permits. (That's better than someone pushing the team to take more work.)
  • Typically, the total allowance for a stretch objective or goal is 10%–15% of the total capacity of the team.
  • On the task priority list, the stretch goals should be the lowest priorities.


Benefits

Some teams prefer stretch objectives and goals because they provide the following benefits:
  • If the team has finished all committed tasks before the sprint end date and has additional time, they need not wait for the next sprint for their next task.
  • Because of early delivery, it shortens the feedback loop for the stretch goals/tasks.
  • It helps to save on the replanning effort if the team finishes all committed tasks before the end of the sprint.
  • Although the stretch goal is not committed work from the team, it works as a motivational factor if they can address those additional tasks.
  • If any team member joined in mid-sprint (e.g., a team member reduced his leave or vacation and joined), the stretch goal provides work for the added team member.
  • It helps to increase return on investment.
  • If a stretch objective is completed in the sprint, it will increase the velocity of the team.


Things to avoid

Although stretch goals have their benefits, those benefits are not realized when a team (or individual) uses the stretch goal the wrong way or for the wrong reasons.

Avoid the following pitfalls:
  • The team undercommits intentionally in order to add stretch objectives or goals.
  • Management or other stakeholders forces the team to complete stretch objectives within the sprint as well as the committed deliverables.
  • The quality of the committed work is compromised because of the stretch objectives or goals.
  • The team works on stretch goals before finishing committed tasks.
  • Stretch objectives are considered for planned velocity in the sprint.
  • Sometimes the team is eager to work on stretch objectives, but that does not mean that if the team works on stretch objectives, they will be considered a high-performing team.


Conclusion

We have seen the purpose of stretch objectives, and we've also discussed the dangers of misusing them. So the most important question is whether we should plan for stretch objectives. The answer is at the team's discretion.

Although Scrum does not explicitly mention stretch objectives, what do we do when the team finishes all the stories for a sprint before the end of the sprint? We pull more stories from the backlog. Thus we cannot say that executing on the stretch objective is bad.

Everything depends on the team's maturity and how they plan the stretch objectives in their sprints. Last, but not least, it is very important, and worth repeating, that nobody push a Scrum team to complete stretch goals or additional tasks within the sprint deadline.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 2 (3 ratings)

Comments

Aart Wessels, CSM, 9/22/2016 6:41:51 AM
Well, in the end of your article, you already describe the 'normal' process. When all work in the Sprint is done, you can select the next high priority User Story from the backlog. So when looking at the root-cause for stretch goals, I feel this is 2-fold:

1) To force the Product Owner has enough User Stories ready in the backlog to start working on, because by adding them to the Sprint, the User Story must be 'Ready'
2) To satisfy the customer. "We're not sure we'll be able to do it, but don't worry, if you insist, we'll add it to the Sprint as a stretch goal"

I know what I'm writing is rather black&white, but I am not sure about the added value, assuming you have a properly groomed and prioritized Product Backlog.
Karl Barthel, CSM, 9/23/2016 1:36:24 PM
Let me start by admitting that I'm a recovering PMP and have tried stretch sprint goals in the past before I saw the light. I'm also a SPC4 and teach SAFe to teams and leaders. Now, on to the explanation as to why stretch goals in an agile environment are a BAD idea and how they are different from stretch objectives in SAFe.

Let's start with stretch goals in Agile, specifically Scrum. When a team creates its Sprint Goal and pulls work from the Product Backlog into its Sprint Backlog, they are telling the P.O. that they are comfortable in completing that work that meets the Sprint goal in the sprint. Stretch goals are not needed because there is an understanding with the Product Owner that should the team complete all of the Sprint Backlog items it pulled, they will have a discussion with the P.O. to determine what other Product Backlog items may be added to Sprint depending on priority of the items in the Product Backlog and the time remaining in the sprint. In short, there is no need for a stretch goal. Another thing to consider is if the P.O. is "pushing" the team to stretch goals, he is saying, "I don't trust you when you say you have enough work in the sprint". If the P.O. has trust issues with the team, there needs to be some serious discussions with the team or he/she shouldn't be the P.O. Perhaps the environment isn’t suitable for Scrum or any of the other Agile frameworks. Do we need go back and re-discover the core values of Scrum (Focus, Courage, Openness, Commitment, and Respect)? How about the 3 pillars of Scrum (Transparency, Inspection, and Adaption)? Many of these are based in trust among the team and with the P.O. If the team doesn’t feel safe in the environment to be transparent and open, there’s a deeper problem in the organization that stretch goals won’t fix.

Now let’s cover stretch objectives in SAFe. Objectives in SAFe don’t directly tie to a specific feature or PBI, rather they are a statement of business value and technical goals that a group of work will deliver within a program increment (PI). They are meant to be a verification that technical teams understand the business intent that their work is to support. Stretch objectives are objectives that a team lists with their planned PI objectives with the understanding by the business and technical teams that they will do their best to deliver to them, but not commit to them. In other words, they act as a buffer within the PI that support things like economic stability, reliability in delivery confidence and adaptability to changing priorities within the PI. The concept of stretch objectives in Agile are sometimes viewed as conflicting concepts, or even blasphemy by Scrum whitecoats, but there is a benefit to them if you can get past the idea that they break the Scrum framework. If you are still reading this and the words haven’t transformed into blah blah blah, then I urge you continue reading about stretch objectives at scaledagileframework.com.

So what am I really saying? Don’t use stretch goals in Scrum for your teams. If you are on a SAFe Agile Release Train, use stretch objectives in your PI planning events as well as pre and post PI planning events but with the understanding of their intent. Don’t morph stretch objectives into something they are not; use them only as intended (and, preferably, after being trained in SAFe).
Aart Wessels, CSM, 9/26/2016 9:34:21 AM
Well-phrased Karl, thank you.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe