Why stretch goals are stupid
In case there was any doubt from the title, "stretch goals" are idiotic, wasteful, and counter productive. This company I'm at has been using them and I find them to be a reprehensible practice.
Stretch Goals discourage accurate estimation
By their very nature stretch goals are based on the assumption that the team has excess capacity that is available to meet more goals than those firmly committed to. Because of the value traditional project managers place on being able to "stretch" and do more work than was initially estimated, this will become a self-fulfilling prophesy. Team members will start to pad their estimates in order to make stretch goals practical. Inaccurate estimation ruins a team's ability to track velocity.
Stretch Goals reduce overall quality
When team members complete their minimal level of tasks and still have time in a sprint, they often will refocus on current tasks in a new manner, like adding additional test automation, code refactoring, or design reviews. The presence of a stretch goal pre-empts this good behavior by instead asking team members to take this extra time and apply it to a new (and likely unreachable) goal. In extreme cases the team will start cutting corners on mainline features (which are higher priority) in order to begin work on stretch goals.
Stretch Goals reduce team ownership of tasks
What I have witnessed here is that in having the scrum master press for stretch goals every sprint, the team stops acting as if it owns the tasks and instead goes back to a traditional project management-engineer type relationship. Since the story commitments a team makes are being constantly overruled by the addition of a stretch goal, team members start to change their behavior to the point where they meekly wait to be told what to do instead of actively participating in the planning process. End result: devolution into mini-waterfall behavior.
Stretch Goals discourage accurate estimation
By their very nature stretch goals are based on the assumption that the team has excess capacity that is available to meet more goals than those firmly committed to. Because of the value traditional project managers place on being able to "stretch" and do more work than was initially estimated, this will become a self-fulfilling prophesy. Team members will start to pad their estimates in order to make stretch goals practical. Inaccurate estimation ruins a team's ability to track velocity.
Stretch Goals reduce overall quality
When team members complete their minimal level of tasks and still have time in a sprint, they often will refocus on current tasks in a new manner, like adding additional test automation, code refactoring, or design reviews. The presence of a stretch goal pre-empts this good behavior by instead asking team members to take this extra time and apply it to a new (and likely unreachable) goal. In extreme cases the team will start cutting corners on mainline features (which are higher priority) in order to begin work on stretch goals.
Stretch Goals reduce team ownership of tasks
What I have witnessed here is that in having the scrum master press for stretch goals every sprint, the team stops acting as if it owns the tasks and instead goes back to a traditional project management-engineer type relationship. Since the story commitments a team makes are being constantly overruled by the addition of a stretch goal, team members start to change their behavior to the point where they meekly wait to be told what to do instead of actively participating in the planning process. End result: devolution into mini-waterfall behavior.
posted by nitpickable at
10:33 AM
0 Comments:
Post a Comment
<< Home