Team Velocity is *NOT* a Performance Indicator
Scrum uses a concept called “Team Velocity” to measure how much work the team accomplished in the past iteration. Velocity is usually measured in Story Points which themselves indicate the complexity of a task (more on Story Points in a later post). Velocity is used in Sprint Planning meetings as a “Yesterday’s Weather” indicator of how much the team can reasonably achieve in the upcoming Sprint.
So why do I claim is it not a Performance Indicator?
Performance is measured as throughput by time, not amount of work by time. Simply put, if you start mixing up performance and velocity and set performance goals, your team will game the estimated Story Points to achieve your goal – but the throughput of the team in a given iteration won’t go up.
My advice is to measure performance of a Scrum Team as Business Value points per release (or if you have to, per iteration). This forces the Product Owner to quantify Business Value (relative sizes are OK, but they need to be numerical) and has the additional advantages of ensuring the team works on high-value stories and of highlighting when ROI drops off (the team is still working hard, but the stories have less and less value), which is the moment to put the project on Hold and give the team higher priority work.
If you think that this definition of performance places too much responsibility on the Product Owner (“it’s not the team’s fault if there are no high value stories in the Product Backlog!”), consider this: who pays for the team’s work? how productive is a “very busy” team working on low value stories really?
Your comments are welcome, especially if you disagree!
Filed under: Uncategorized | Leave a Comment
Tags: indicators, product owner, productivity, team, velocity
No Responses Yet to “Team Velocity is *NOT* a Performance Indicator”