Velocity, Capacity and Productivity
This piece examines how productivity should be measured in agile software development projects and its relationship to team capacity.
I agree with the perspective that velocity is not productivity. We should be cautious when applying performance metrics, particularly productivity measures and capacity assessments.
The Bug-Fixing Problem
If capacity equals productivity, how should teams count bug-fixing work? These tasks don’t add new business value — they restore previously promised functionality. Yet teams expend real effort on them, making these estimates crucial for both velocity calculations and capacity planning.
Alternative Productivity Measures
Simon’s approach suggests measuring productivity through business outcomes rather than output: revenue generated per iteration per unit of story estimation. Martin Fowler counters that meaningful productivity assessment may take years post-release.
The Goal-Setting Framework
If a team doesn’t have a goal, how could it pursue its objectives?
Teams need clearly defined goals to guide development decisions and enable meaningful retrospectives. While broader system thinking matters, teams require specific targets they can control and influence.
The Measurement Boundary
Teams should measure success at the point of story acceptance — when work delivering business value is completed. Beyond this point, external business factors beyond the team’s control determine actual revenue impact. Teams can only optimize and adapt their performance up to this boundary.