Using Velocity Charts and Burn-Downs to Drive Development

Posted by Jason Smith - 28/02/10 at 01:02:20 pm

Imagine you’re the driver in a car cruising along the Seven Miles Bridge in the Florida Keys. Sunny day. Clear. There are no other cars, and you’ve been given permission from the Florida Troopers to go as fast as you like – so you’re cooking along at 80-90 miles an hour.

Now imagine you’re doing that with someone in the back seat holding their hands over your eyes and letting you take a 3 second peek every 30 seconds or so.

Sound like fun?

Not if you’re anything like me. I’d want to know if I were getting anywhere off track as soon as it happened. Hundreds of pounds of steel, plastic and simulated walnut trim develop a fair bit of momentum. The only way I’ll keep that car under control at that speed is slight steering adjustments as soon as I notice I’m drifting.

So why do we run projects like that? How often have we sat through projects with a weekly status report where folks give the old “we’re on track” for the first 10 weeks of a 12 week project, followed by a “we’re 90% done” for the next 3 weeks? Or we’ve taken on an 18 month project, and only found in month 16 that it’ll take at least 24 months. How well can a project running under a full head of steam radically change directions without crashing and burning?

Velocity Charts (also called Burn-Downs or Burn-Ups) are the simplest way to get immediate visibility into whether a project is drifting off course (and are incredibly effective at identifying fairly early in the process when a project will really be completed).

The way they work is extremely simple and incredibly accurate.

Estimate Sizes

Given a set of tasks, make an estimate of their sizes (often called “story points” or “task points”). There are a number of rules to get good estimates, but the simplest approach uses these rules:

  1. The estimate is unitless. It’s not hours. Not days, weeks or months. It is just a number. Each task is estimated in size relative to the others.
  2. The values we use are 0, 1, 2, 3, 5, 8, 13 and infinite/too big (each value is the sum of the preceding 2 values). Or you can use a doubling sequence: 0, 1, 2, 4, 8, 16 and infinite/too big. These values are used for the following two reasons:
    • Humans are better at saying a task is “bigger than that other one, but not as big as this” but we have problems identifiying precisely how much bigger. Both series account for that.
    • Humans seem to not be very good at estimating sizes that are more than an order of magnitude difference, so we cap it at 13 (or 16)
  3. If this is the first time you’ve done this, simply identify the smallest task in your set and assign it a value of 1. If this isn’t the first time you’ve done this, compare this to your last project’s items of size 1. Is it the same size as the first? Give it a 1. Bigger? Twice as big? Three times? Give it the appropriate number. Repeat this for each task you’ve identified, comparing their relative sizes to the previously sized tasks.
  4. Any task bigger than a 13 (or 16 if using the doubling sequence) must be broken down into smaller pieces. The likelihood of not understanding the task well enough is pretty high
  5. Record these tasks into a list.

Notice that throughout the exercise above, there is no estimate of time. History demonstrates we software people profoundly suck rocks when estimating how long it takes us to do something (I’m convinced our egos get in the way). This is all about relative size.

Track Progress

This is where time enters the picture – not as a guess or estimate, but as a measure of what’s really happening.

  1. Write your estimates down on a grid (a spreadsheet works beautifully here). First column is each task, second column is the associated size. The rest of the columns will be updated daily.
  2. Regularly (I prefer daily, but you can get away with weekly if you like driving with kids’ sticky hands over your eyes), have a quick standup meeting with the team (shouldn’t last longer than 15 minutes). Ask them what items from the list of tasks are complete. If (and only if) the task is complete, enter a zero in the first empty column for that task, otherwise carry over the size from the previous day.
  3. Sum the columns and generate a line or bar chart from the sums.
  4. Calculate a regression line from the chart (Excel calls it a Series). The negation of the slope of that line is the Velocity for that team for that period. So, if the slope of the line is -1.67 and we are doing this daily, it means the velocity is 1.67 task points per day.
  5. Multiply your Velocity and the sum of remaining sizes, and you have a good idea of the number of periods (days if you’re doing this daily) of time before the project is complete.

Here’s an example chart:

Generated from this data:

Caveats

The velocity’s predictive power improves with more samples, so your first 3 or 4 days won’t give you a very accurate prediction of when the project will be done. Each sample improves things tremendously though.

Different teams have different velocities, based on the size of the task they used as their size 1, as well as the size of the team. As a result of this, DO NOT USE VELOCITY FOR COMPARING THE EFFECTIVENESS OF TEAMS – IF YOU DO, YOU WILL BE COMPARING APPLES TO VOLKSWAGENS AND THE TERRORISTS WILL WIN.

Additional Information

An excellent way to generate even more accurate size estimates can be found here:

http://www.planningpoker.com/detail.html

You can get additional information on Velocity Charts at these locations:

http://www.versionone.com/Resources/Velocity.asp

http://www.controlchaos.com/about/burndown.php

The following is a great way to do burn-downs in the face of changing requirements (that never happens, right?):
http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown

Powered by WordPress with GimpStyle Theme design by Horacio Bella.
Entries and comments feeds. Valid XHTML and CSS.