Some Thoughts on Project Velocity

Companies I work with desperately want reliable estimates.

In reality, they need them so they can run their business. Businesses really want a crystal ball to look out into the future... to know pretty much what they are going to get, when they are going to get it, and some idea of what it is going to cost. The problem is that they need this information when approving projects... when making commitments to the market... and this is when we have the least reliable information about what we are building.

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.

Comments

[Dave Nicolette]

I wonder if they only think they need estimates.

What if development teams worked directly for the business units that need business applications, while the central IT department handled things that really have to be centrally-managed, like the network and the SOA infrastructure, etc?

Then teams could build individual features for their departments at the time the features were needed; customer pull, single-piece flow. No projects, no estimates.

Thoughts?

[Mike Cottmeyer]

I have another post in me, probably once I get through my current rant on Scrum roles, that has to do with team structure... business alignment... SOA... business objects.. etc.

I think ideally that agile teams are arranged around business services or organizational capabilities (think SOA). Those teams deliver value based on business need for that service. Those services are shared and may live in IT, per your example.

I also agree that you should have business teams that are responsible for consuming those services to deliver business value for internal or external customers. Business value is derived by combining services in a way that creates value for your customer.

Problems arise when there is no direct connection between building services and delivery to the customer. Might be waste?

You could also have problems when business teams want to build features based on business objects that don't exist yet. Building both in parallel can introduce dependencies.

If teams were delivering features based on services that were already in place, I can see your point around not doing estimates at all.

Estimates, even in story points, become a way to communicate progress and coordinate activities in addition to predicting when we will be finished.

More complicated in my head than I can articulate here. Again, it is a problem of scale... and to a lesser degree being in transition from traditional to agile.