# On averages, history and predicting the short term future

Suppose you know a teams average velocity in story points to be 6 per two week sprint over the last year. Nothing interesting has changed (same team, same problem domain, out of holiday season…), what do you think is the correct answer to the following questions:

1) How many story points will be completed during the next half year?

2) How many story points will be completed in the next 4 sprints?

3) We estimate the final story to be 6 points, should we invite the Fortune-100 CEO's for the crucial product launch next month?

My first answer to these questions would be:

1) 6 months = 13 sprints, the average is 6 points per sprint so we will complete 13 x 6 = 78 points

2) 4 sprints means 4 x 6 = 24 points

3) The average is 6 points per sprint so in the last sprint we can do 6 points worth of business value, so yeah, why not?

But as always in our line of business, the answer should be ‘it depends’.

Suppose in the past the teams track record of story points per sprint is as follows:

`6, 6, 6, 6, 6 … 6`

If that is the case I would say the answers above are probably correct. The team completed 6 points since forever so what are the odds they won't complete 6 points next sprint?

But what if history looks like this:

`11, 11, 1, 1, 1, 11 … 1, 11`

The average is still 6 but will the next sprint be a '1' sprint or a '11' sprint? You can still feel comfortable about the coming 6 months. History shows a succession of 11 and 1 sprints with about 50% probability each so intuitively we can say we will complete about 78 points, give or take 5.

Predicting 4 months ahead is trickier but if we cut ourselves a little slack in the form of optional functionality and maybe a little overtime we can still feel comfortable about delivering on time.

Predicting the outcome of the next sprint is scary however. A succession of 1 and 11 sprints yields an average of 6 with an average spread of 5. If the release hinges on completing 6 points we're taking a really big risk here. The team shouldn’t commit to 6 points, but more importantly, the product owner shouldn't even ask them to commit to 6 points because no amount of overtime or bullying or whatever will save the release if we happen to run into a 1 point sprint.

If you insist on throwing math at this problem, you might try Mountain Goat’s Velocity Range Calculator (pointed out to me by my colleague Martien van Steenbergen): http://www.mountaingoatsoftware.com/tools/velocity-range-calculator. Which will happily give you a mathematically sound answer, but in my opinion these kind of questions are better answered on instinct.

Imagine you are in front of lots of highly paid executives demo-ing the new version of your software. Now what would the answers be? In my case I’d say the correct answers to the questions are:

1) 6 months, 78 points should be no problem

2) 4 months, 24 points should be no problem, but it would be wise to carefully consider priorities and make sure we can drop something if necessary

3) 2 weeks, 6 points, no way

## Comments

> 6 months = 13 sprints, the average is 6 points per sprint so we will complete 13 x 6 = 78 points

On a short term, a stable velocity is a good prediction tool. But on a long term, can we forget that velocity is both a prediction tool and an indicator about how we are doing now and will hopefully change?

Isn't it dangerous to communicate mathematical estimations based on the model, when we want to be allowed to change the model? In your experience, would you consider 6 months as still short enough to communicate estimation? Or do you think it is possible to give the estimation to a custom whom won't take it for granted and will still accept to change the plan in three months if the velocity decide to change?

thank you,

fabien.