We are using Scrum and our user stories are estimated using the Fibonacci sequence. I understand the benefit of using the Fibonacci sequence for estimates. In all references to velocity it is mentioned it is a simple sum of all the estimates. This is a linear sum though. Two size 5 tasks do not equate to ten size 1 tasks or say five size 2 tasks. How then do you calculate velocity?
Calculating velocity is relatively straightforward if and only if you treat it as a rough estimate for forecasting. If your metrics imply great precision, you're using velocity wrong.
Having said that, the two most common techniques are:
- Trailing average.
- Median with confidence intervals (e.g. "a range").
There are many variations on these techniques, but they all basically define an educated guess about how much work the team is likely to complete in the upcoming Sprint. It's a capacity planning tool for Sprint Planning, a schedule estimation tool for Release Planning, and a baseline to track within the current Sprint—that's it!
The easiest method is just to find the mean of a sliding window over an historical period. Pragmatically, I find that at least three Sprints are required to find a useful mean. You aren't looking for perfect accuracy; you're just looking for a reasonable estimate of your team's capacity for the upcoming Sprint after applying whatever fudge factors are relevant.
For example, if your last three Sprints had delivered total story points of 5, 8, and 5 then you'd arrive at 6 points as your baseline velocity estimate:
# Sum of Sprints, averaged and rounded down. ((5 + 8 + 5) / 3.0).floor == 6
After accounting for fudge factors like vacations, supply chain delays, or other temporary effects on team capacity, you arrive at a likely target for the upcoming Sprint. Based on the team's historical velocity above and assuming no significant fudge factors apply, six story points would be a reasonable forecast of the team's capacity for the upcoming Sprint.
Regardless of the number of story points completed in the next Sprint, you simply adjust your average accordingly. For example, if you deliver 7 points then your next average might be based on Sprints delivering
8 + 5 + 7, which still yields a forecast of 6 points because it's generally better to underestimate than overcommit.
You can calculate your mean based on a longer time series, or make your calculations more complicated, but this often just leads to needless complexity. The trailing average method is often "good enough" for estimating how much work the team should accept during Sprint Planning.
Ranges with Confidence Intervals
If you can't get your Scrum Team or management team to understand that velocity is an estimate, then you can make it more explicit by describing it as a range with a confidence interval. You can use a tool like Mountain Goat Software's Velocity Range Calculator to perform the following formula:
Assuming n observations, the formula for calculating a 90% confidence is given by
j = n/2 – 1.645 (n*0.25)0.5 k = n/2 + 1.645 (n*0.25)0.5
where j and k represent the velocity observations to use. Round results up to the next highest value.
Given five or more inputs like
5, 7, 6, 3, 5, 8, 6, the tool will give you both a median and a 90% confidence interval similar to the following:
For velocity values of 3,5,5,6,6,7,8
You have a median velocity of 6 and there is a 90% likelihood that
your actual velocity will fall between 3 and 8
Outside of the tool, you can make this more complicated by adjusting the sliding window or calculating other confidence intervals if you like. However, a range basically sets people's expectations more clearly by stating that estimates and averages may have volatile swings. One way to express this range in a more narrative fashion would be:
"We're targeting 6 story points, and will probably deliver between 3 to 8 points this Sprint."
However, a range is not inherently a better or more accurate predictor of the future than the trailing average. It can be more informative, certainly, but a given Sprint could still deliver zero story points, or a large value outside the expected range. A range is better at communicating variability, but if you haven't done a good enough job at explaining that estimation is not a money-back guarantee then folks without a statistical background are just as likely to tell you to shoot for the upper end of the range instead of the (pragmatically more accurate) geometric mean.
Your mileage—and the amount of aspirin you need to keep on hand—may vary.
If 2x5 does not equal 10x1 then your relative sizes are off. A 5 means it 5 times more complex then 1 on average. On average it will also take 5 times more time to complete.
Still velocity is defined as the number of points you achieve in a Sprint. Just sum them. Then it is wise to average velocity of the last three Sprints, something Jeff Sutherland calls Yesterday's Weather.
Now you can use this number to forecast how many story points the team will probably complete in the upcoming Sprint or Sprints. More detail is a waste of time.
A 5 means it 5 times more complex then 1.That isn't necessarily true, especially if you are using a Fibonacci sequence-like point structure. If your options are 1, 3, 5, 8, 13, 20, 40, two 5s may not be the same. A 5 is going to be bigger than a 3 but smaller than an 8. But there's a lot of variation in there between a 3 and an 8. A 5 can range from "slightly more complex than a 3" to "slightly less complex than an 8".– Thomas Owens ♦Jun 2, 2017 at 17:55
2I added "on average". Really it doesnt matter on the grand-scheme of time and estimates. It is a bucket system, so yes a 5 could be a 4, but if it is bigger than a 5 place it in 8 bucket please. If you see the scale as buckets of water, would you try to put 6-7 gallons in a 5 gallon bottle? Personally I think if you are deep into an Agile way of working where you optimise for value, you drop estimates anyways. Some are spot on, some are totally off, but if you want to make a plan you need something. Something that forces developers to communicate and think about uncertainties. Jun 2, 2017 at 21:08
@NielsvanReijmersdal I think your answer would be a lot stronger if your comment was inlined. Your point about the bucket system is spot on, and clarifies the estimation process with the Fib sequence for those who are used to a more linear scale.– Todd A. Jacobs ♦Jun 6, 2017 at 5:42