Stretch Targets in Agile Teams
So you have a team with a velocity of 85 points per Sprint and you decide they could do more. So you set them a stretch target of 100 points for the next Sprint. What happens next?
Because you get what you measure, you might get 100 points. This is the worst possible thing that could happen.
Because your focus is on the number of points, what short-cuts will be made to meet the stretch target? Maybe people stop pair-programming so the team can work on more things concurrently. Maybe people will skip writing tests. Maybe they’ll fix up a feature and then skip refactoring things to make it easier to maintain. This will lead to more bugs and problems maintaining the pace indefinitely, so you’ll get your 100 points now, but you’ll get stung later.
This isn’t the only potential outcome. Maybe the team will start inflating their story sizes to achieve the 100 points. This is a better case than actually getting 100 points. This will hopefully mean you get the right quality and won’t create problems for the future. If the team inflates their estimates, you’ll get a better outcome – but why should they have to subvert the stretch goal if they know they are being asked to compromise on quality and good practices.
Another outcome is that the team will fail. They won’t be able to complete all the work in the Sprint. Although this is probably better than achieving the 100 point stretch and is more transparent than the point-inflation, the damage to team morale could mean your velocity takes a hit.
So why are you giving out stretch targets anyway? Do you think your team is lazy? Are they not working hard enough? What is it you really want?
Hopefully you are just trying to guide the team to becoming more effective. You are just doing it in the wrong way. The fact that you think the team needs to be pushed in order to do the right thing shows a lack of respect for the individuals on the team.
The correct way to approach the issue of continuous improvement is to give the team context. If you aren’t running retrospectives, introduce the concept to the team. If you are zoomed out and can see issues the team might be missing, raise the problem at the retrospective and let the team design their own solution. This give you the chance to make sure there is a problem to be solved and to design an appropriate way of presenting it.
Stretch targets are just one example of dumping a poorly designed and destructive solution on a team, without properly thinking about the problem it is meant to solve.