# Ranged Burndown Charts

Previously I discussed the difference between gross velocity and net velocity and now I’d like to show why they’re important.  A ranged burndown chart, an extension to normal burndown charts which apply both the gross and net velocity, is shown below.  Where a burndown chart uses the (gross) velocity to predict a potential end date, and by extension gives a feel for the potential project cost, a ranged burndown gives a potential range of end dates/costs.  Giving a ranged estimate is a known best practice in the IT community. Because it’s possible that functionality can be dropped from a release part way through a project, perhaps because of a major shift in strategy or in an effort to hit a desired date, the net velocity will exceed the gross velocity that iteration.  In this case our advice is the use the change in requirements from the previous iteration to calculate the net velocity.

Note that this blog posting is excerpted from Chapter 10 of the book Disciplined Agile Delivery.

### Have any Question or Comment?

#### 7 comments on “Ranged Burndown Charts” ###### Ray Pitch

How are the projections made? There are two variables to consider

a) Projected (average) velocity and
b) Projected rate at which new work is added

Both variables will have a range of probalbe values but what algorithm is used for this? I’ve seen Historical average +/- “x”% and Historical average +/- standard deviation, so what’s best practice? It’s likely not clear from the example, sorry about, but I’m using actuals from the previous iteration. So, if at the end of iteration X there’s 300 pts on the stack, the gross velocity was 30 pts and there was 10 pts of stuff added (giving a net velocity of 20 pts), we’d estimate between 10 (300/30) and 15 (300/20) iterations left. ###### Lee Lowe

What if your net velocity is a negative number? Gross velocity is 30 pts but 40 pts of stuff is added? How does that affect your calculation? Good question. There are several options:
1. Take an average of your velocity over several iterations. This is common practice for non-ranged burndowns/ups that will likely solve the problem. BUT, there’s still the potential to have a negative net velocity in this situation too.
2. Reset the net velocity to 1 – You’ll get a end date in the distant future.
3. Set the net velocity to 0 (or leave it at negative 10) – Then calculate the end date as never, which in this case would be the actual answer because you’re losing ground every iteration.