Velocity is not Progress

Introduction

Almost every team is 'Agile' these days. Most teams go through the motions of putting cards on walls, of standing up each morning, and of tracking velocity. Often the velocity is used to forecast delivery dates for some features.

While velocity can be useful, you have to be careful when forecasting to prevent unrealistic delivery dates.

A predictable plan

Suppose you have a project that hopes to deliver 10 features. We might look at each feature and guess that each feature is about 10 story points based on how difficult they look relative to similar features the team has done in the past.

The team might already have been running for a while, and its current velocity might be about 10 story points per week.

This might lead to a simple plan like this:

Iteration

You create the first feature on plan. The users review it and come back with some feedback. The feedback is positive, you're going in the right direction, but some changes are required.

You write some more stories to incorporate the feedback. The extra stories are estimated at about 5 story points. The stories are pulled into the next iteration, and the plan might now look like this:

Velocity is still 10. That is, based on yesterday's weather, the team will be able to do about 10 story points in the next iteration. It's tempting to say that the project has slipped by a half a week.

More realistically, the progress has slowed from 1 feature = 1 week, to 1 feature = 1.5 weeks, and the total project time is more likely to be 15 weeks instead of 10 weeks:

Velocity is great. Progress, not so much.

It is possible that the initial feedback from the first feature was cross-cutting. If this is the case, then the team might be able to incorporate that feedback into future features so that they continue to be produced in 1 week. The reality will lie somewhere between these two extremes. The project might have genuinely only slipped 0.5 weeks; I find that projects are rarely that lucky.

Bugs

At some point, bugs will be uncovered. They might be categorised as issues, or observations, but they still need time to fix. You might find that for every feature you write you get a couple of these issues. You might estimate them and schedule them, or you might just fix them. Either way, you need the time to investigate them. Now your plan might be:

Again, while these bugs might not reduce your velocity, they are not progress. So instead of your plan should expand accordingly. In this example, the length of our plan has nearly doubled. We might not be happy about it, but it might be considerably more realistic.

Note that the best way to uncover any issues is to go live with the software. If you're not pushing your features live, then you could potentially be storing up a lot of issues for the future. This might give you a false sense of security in your plan.

If you do nothing else, push your features live as soon as possible.

Variance

This only scratches the surface of things that can derail a plan. The team members might have surprise holidays, or get sick. There could (will) be turnover in the team as people come and go, and undoubtedly there will be changes in direction for the project.

This natural variance can cause devastation to a plan.

Conclusion

So this might leave you wondering what to do if planning is so difficult? Deliver small. And often. To live.

The best advice I've seen for managing that risk is in James Shore's "The Art of Agile Development"; read the chapter on risk management. Then read it again. It's invaluable advice.

I find this fits nicely with my favourite heuristic of taking the estimates and doubling them for a ballpark figure of when things will be up and running.