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