Background

This relates back to the somewhat thorny issue of estimating how long things will take so people can plan how to allocate resources.

As creators of value giving stuff we need to be able to make promises to our friends and paymasters that they will get the things they need to be able to do their business. Enterprises of all stripes want to know that they can invest a specific amount of cash and have something that will make more cash. Preferably more than they invested, and in a timescale that isn’t too far in the future.

The problem is they can’t. When you are creating something new it is by nature an unpredictable beast. Instead what you have to do is take steps to minimise the cost of mistakes and maximise the results you get.

The cost of mistakes is also why we also work in short iterations because we know we are human and will make them. This isn’t a bad thing, it just lets us experiment and learn without having to bet the farm. Because of this there is a disconnect right at the heart of what’s laughably called software engineering. Businesses invest to make money, any software you create is an investment. However, you can’t guarantee the results or even how long it will take to get somewhere useful and people don’t like that.

The quest for agility

Agile was a response to this, it came from the makers of software who said that they couldn’t reasonably commit to very large projects with any degree of certainty. It’s all about mitigating the risks by trusting people to think small and act small in well bounded contexts. So you eat an elephant one bite at a time – you develop large systems one small iteration at a time, and the small iterations allow the business to change its mind relatively easily and cheaply as well.

Development is a process and you discover things and questions you didn’t know you needed to answer as you follow it through. Small iterations let you answer these questions before they derail you.

Typically a large system is broken down deliverable chunks, and the chunks into projects. The projects become a list of tasks that are small enough for one or two people to understand and deliver. These are then sorted into priority order and a series of iterations are planned roughly.

Then we plan an iteration in detail. Iterations are time boxed. No task should take more than a couple of days at most, and we try and work out how many we can get done in each iteration.

This is where velocity comes in.

Velocity explained

The team get together and give each piece (or story as it’s called in some schemes) an arbitrary amount of effort they think it will take and allocate it a number of points depending in the difficulty. It’s important to emphasise here that the key word is think. They don’t actually know, because if they did they’d be playing the lottery and living the high life. It takes little time to do this and they work out what will fit into the next iteration, plus a couple of extra things that they could fit in if things go well. It’s also not effort, as such, but a yardstick that lets you work with the relative sizes of tasks.

Over time they get a feel for how many of these magical points they can get done in an iteration, and how many certain types of task may take.

Very strong concept to emphasise here is that there is no science in this, the points are what that team think for that specific iteration. The points measure nothing and are only to give a yardstick of what can probably be fitted into a given iteration by that specific team.

So …

  • If you try and use velocity to compare teams you aren’t going to be able to say anything meaningful, and just piss people off.
  • If you say things like you only got 23 points done this iteration and 25 last one, you need to work harder to a specific team they can easily fix it by adding some nonsense to the plan for the next iteration. You’re also demonstrating you just don’t get it.

To complete the process when each iteration finishes the team traditionally check back with the business representative (often called the business owner) and make sure that what they’ve built fits with the business needs. This is known as the demo. If they’ve been doing technical stuff to support future iterations there may be nothing to show.

Good teams then review what they got done in the last iteration and look for ways to improve.

Velocity is how many points a given team gets done in an iteration. It’s worth measuring because you can start finding out whether or not:

  • The project is possible with the people and resources you have
  • The team find certain kinds of task difficult and maybe need some mentoring for them
  • The communication with the business is being properly managed
  • Some tasks in particular areas are taking a lot longer than first thought – you can go find out why before it kills everything

and you can find this all out very early so you can fix it before you’ve wasted huge sums of money invisibly choking on the proverbial elephant.

So velocity is a simple rule of thumb that lets you make sure you can keep your promises and head off any problems early. It’s not a management tool to get more productivity. In fact it has little to do with it. For example a team of very experienced people who’ve been working together a long time might well be able to deliver a lot more  in an iteration, but could easily allocate the same number of points as a less effective team because that’s what they’re comfortable with.  If you were some clueless spreadsheet jockey working far away from the delivery you would have no way of knowing this.

The number is meaningless, except as a rule of thumb for a specific team at a specific time. It’s a very blunt instrument and changes anyway as the teams get better or change their practices.

Consequences

You can’t create a pretty gantt chart and say this will be ready by the 12th of November because you don’t know for sure when things will finish. You can get a range of dates once you have some data. If it must be ready by a specific time you can either use the knowledge you gain to manage scope or make sure that the parts of the project that must ship to make it workable by that date are done first.

You can also get creative. For example Basecamp wrote their billing module after they delivered their first fully featured version because it gave them short term time to put more into the product and left them 30 days to create the billing module.

In software there are no hard and fast rules and you need to take the time to work out how to get the business what it needs, which is capability, not functionality. That’s a topic for a different post.