Some Thoughts on Project Velocity

This need can result in pretty bad behavior on the part of both management and teams. To gain some sense of certainty, management does things like ask teams to provide estimates in real hours... and then hold the team accountable for delivering exactly according to that estimate. Faced with an impossible situation, teams are incented to game the numbers. They overestimate the project... to provide some necessary buffer... thus resulting in overinflated budgets. All this leads to a total lack of trust on both sides.

Velocity is intended to bridge the gap between management and the team. Teams get to measure project scope in relative units such as story points. Point estimates are specific to the team and measure how big one feature is relative to another in the backlog. Teams then begin building the features and measure how much of the backlog they are able to complete every iteration. After a few iterations, the team should have a pretty good idea how long it will take to complete the project.

Iterations to Complete = Backlog Size/Points per Iteration

For this equation to work, for velocity to be a meaningful metric, it has to be predictable... past performance must at some point become indicator of future performance.

Furthermore, velocity is only relevant to the business if we have a decent understanding of the overall scope of the project. That means we have to have a meaningful view into the backlog... for at least the upcoming release... sometimes the entire project. Measuring velocity against a constantly changing backlog doesn't give me a whole lot of information. If we are going to have any idea of what done looks like at the project level, we need to understand both backlog size and velocity... and understand how these metrics might change over time.

Velocity is fundamentally a measure of team throughput. How fast are we able to go... iteration over iteration... against a relatively stable queue of product features. These two metrics are the only thing standing between an agile team and total choas... at least when it comes to overall project performance.

To make all this work... both sides have to do their part. Ask not what your agile project can do for you... ask what you can do for your agile project. Here are a few thoughts on what managers and teams can keep in mind to keep velocity a reliable indicator of project performance... and maybe build a little trust while we are at it.

Responsibilities of Management

Realize that estimates are just that, estimates. As management, we can expect that estimate should get better over time, but what we get early... even in story points... is likely to change. We need to be prepared to deal with change.

Management should only use metrics like velocity as an indicator of project health and to help guide the project into a successful outcome. If management uses velocity as a lever or a performance metric, people will game the system to make the numbers look right. You'll get the numbers you want, you might just not get the product you want.

The size of the backlog has to be stable or the project is out of control. We can't just keep changing our minds indefinitely. We want to defer as many decisions, as long as possible, but we need to have a fundamental understanding of the product we are building and why. Constant churn will slow the team down and make everybody frustrated.

Responsibilities of the Team

Estimates are just that estimates. That said, we are accountable for making them better over time. At some point we have to be able to tell the business what they are going to get and when they are going to get it.

As team members we have to realize that our velocity must stabilize. Stable velocity is the life-blood of a predicable agile team. If we can't stabilize our velocity, the business will always see our project as out of control... because it is. We cannot expect the business to continue to invest never knowing what they can expect to be delivered.

We have to be honest with ourselves and our customers about what it really means to be done at the end of an iteration. Gaming the system to make the numbers look right will kill a project... hiding undone work in future iterations doesn't help either.

From Agile Chronicles