菜单

雷达交互页面中的信息目前只有英文版本。欲获得本地语言版本,请在这里下载相应PDF。

技术

Velocity as productivity

NOT ON THE CURRENT EDITION
This blip is not on the current edition of the radar. If it was on one of the last few editions it is likely that it is still relevant. If the blip is older it might no longer be relevant and our assessment might be different today. Unfortunately, we simply don't have the bandwidth to continuously review blips from previous editions of the radarUnderstand more
Jan 2015
hold?

We continue to see teams and organizations equating velocity with productivity. When properly used, velocity allows the incorporation of \”yesterday's weather\” into a team’s internal iteration planning process. The key here is that velocity is an internal measure for a team, it is just a capacity estimate for that given team at that given time. Organizations and managers who equate internal velocity with external productivity start to set targets for velocity, forgetting that what actually matters is working software in production. Treating velocity as productivity leads to unproductive team behaviors that optimize this metric at the expense of actual working software.

Jul 2014
hold?
Of all the approaches that we might disagree with, equating velocity with productivity has become so prevalent that we felt it important to call it out in our hold ring. When properly used, velocity allows the incorporation of "yesterday's weather" into the iteration planning process. Velocity is simply a capacity estimate for a given team at a given time. It can improve as a team gels or by fixing problems like technical debt or a flaky build server. However, like all metrics, it can be misused. For example, over-zealous project managers attempt to insist on continual improvement of velocity. Treating velocity as productivity leads to unproductive team behaviors that optimize the metric at the expense of actual working software.
Jan 2014
hold?