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

The Bottleneck

Posted by Jason Smith - 20/02/10 at 10:02:47 am

Nearly 70% of all software projects are considered unsuccessful. They are late, over budget and have fewer features than users wanted (and often ones they didn’t want – I’m looking at you, Clippy).

I gotta ask, would this situation exist if we had perfect knowledge of the future?

If we knew the user interface would confuse our users – would we spend as much time as we did implementing it the wrong way? If we knew our design would lead to performance issues, wouldn’t we select an alternate before we were too committed? If we knew the code we just wrote had a bug in it wouldn’t we fix the code before it even consumed a second of QA’s time? If we knew that QA would find a bug in a third party product caused by the way we called the API, would we have altered our design to compensate?

Most of our problems developing software would be solved by knowing, by learning the things we don’t know earlier and faster.

Now consider the Theory of Constraints:

  • Any manageable system is limited in achieving more of its goal by a very small number of constraints.
  • There is always at least one constraint.

In a nutshell, we will see the greatest improvements in our ability to reach our goals by understanding and defeating our greatest constraints.

If that’s so, then software projects are unsuccessful because we haven’t optimized the activity we spend most of our time doing. That activity is not coding, requirements gathering, bug fixing or dropping in an easter egg. The biggest constraint we have is Learning:

  • Learning what the customer wants
  • Learning whether what we wrote is what the customer really wanted
  • Learning how use an API
  • Learning code the guy down the hall wrote
  • Learning when we’re actually going to deliver
  • Learning whether our code actually works
  • Learning why it didn’t in a special case
  • Ad nauseum

Good product developers intuitively understand this. They actively seek out ways to learn faster and earlier.

They learn early that the UI they are doing meets the user’s needs and doesn’t confuse (prototyping and seeking active customer feedback). They understand that it’s orders of magnitude cheaper (in both dollars and effort) to learn about and fix a bug when the bug is introduced (automated unit testing and continuous integration). They understand that the fastest way to help our coworkers learn what we are doing is by collaborating with them (pair programming, daily stand-ups and being colocated). They learn about their risks early by working the risky code early (spike solutions). They know that code that is easy to understand is easier to learn and use (simple design, simple code that expresses intent).

Optimize the process of learning, and we optimize how we develop software.

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