Velocity of the team

Question

If i have been provided with the information of six sprints having story points like 20,21,22,23,24,25,26 then what should be the velocity of the team ?

Answer 1

Usually when people talk about velocity, they actually mean average velocity, so you could just average all of those. Now, teams change and improve over time, so often times we'll use a rolling average of the last 3 - 4 sprints.

Personally, I like to use the last three excluding any oddities (like sprints over Christmas). The reason I ignore these oddity sprints is because including them in the average throws off the number without telling me anything useful.

Answer 2

The calculation part of velocity is straight forward as you can just sum up the story points completed in each sprint and divide it by number of iterations.

This will be 23 in your case for the data that you posted.

However, the whole point of Why to "calculate" velocity is worth mention here...

In Scrum, velocity is how much product backlog effort a team can handle in one sprint. Now, you have vision of last 7 sprints and you know your team on Avg. can handle around 23 story points per sprint. This data should help you to plan projects and forecast release and product completion dates.

Also note that this is just a indication of team's overall output over a span of certain period. Velocity, however, is not forever fixed. It varies from team to team and from project to project.

Once established, velocity can be used for release planning.

Answer 3

TL;DR

You can express velocity in a number of ways. The two most common are the sliding average and the range. A sliding average is generally easier to calculate, and often provides "good enough" data for agile planning. On the other hand, a range can be more effective at setting stakeholder expectations.

Using a Trailing Average

Calculating a standard average (by which most people really the "statistical mean") is easy, so I won't cover that except to say that you only count the story points from completed stories that fully met the Definition of Done. Incomplete or partial stories are simply not done, and always count as zero when calculating velocity.

You provided the result of seven Sprints, but said you wanted to count six. Assuming that what you really want is the trailing average of the last six Sprints, you would discard historical values not in your window and then find the mean of the remaining values. For example, in Ruby:

# Find the trailing average of points delivered each Sprint
# per the Definition of Done, rounded down to the nearest
# whole number.
def average_velocity points_per_sprint, num_sprints
    window = points_per_sprint.last num_sprints
    total_points_completed = window.reduce :+
    avg_pts_completed      = total_points_completed.to_f / window.count
    avg_pts_completed.floor
end

points_delivered   = [20, 21, 22, 23, 24, 25, 26]
sprints_to_average = 6
average_velocity points_delivered, sprints_to_average
#=> 23

You certainly don't need to use Ruby, but this shows how you can find the trailing average for any arbitrary window to find your average velocity.

Expressing a Range and Confidence Interval

You can also express velocity as a range, usually with a confidence interval that statistically describes how likely future values are to fall within the given range.

One way to calculate a 90% confidence interval can be calculated as follows:

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.

You can find the math, as well as an online calculator for this method, in Mike Cohn's Velocity Range Calculator.

Given all your inputs—I'd recommend against the notion of using a sliding window for this methodology, even with statistical outliers—you would end up with:

For velocity values of 21,22,23,24,25,26

You have a median velocity of 23.5 and there is a 90% likelihood that your actual velocity will fall between 21 and 26

Answer 4

Velocity is not something that you can calculate, it is merely the result of summing the points for the PBI completed during the sprint. It is an outcome. Calculating the average (or mean) velocity is largely pointless as it will almost never reflect a future velocity.

TL;DR;

Don't rely on velocity, it can fluctuate wildly with little or know warning, and that is normal. Let the PO figure out what they want to do for forcasting, and let the Development Team figure out how much work to take on for the next sprint.

The nuts and bolts

If you think about the mean, mean of the worst 3, and the last outcome you can get an idea of your cone of uncertainty at this point of time. Based on your fictitious data your cone is about 6 points wide. In 3 sprints that's 18... That's why you can't rely on velocity.

Velocity for the Product Owner

Velocity is useful for the PO to help you create a forecast for future work. I would be really careful with how far out you forecast, 3 sprints max.

Velocity for the Development Team

Velocity can be a guide for the development team to help them select backlog for the next Sprint. However its just a guide and just because your mean is 23 does not mean that the team takes 23. Maybe 30 works for this sprint, maybe 10... It depends on the plan that they come up with.

Velocity for Refinement

You can use the past velocity to get an idea of how much work you need to refine during your Sprint Refinement. Make sure that you have 2-3 sprints of work refined. This is a buffer for changes, both in tactical direction and in Team capacity.

Answer 5

Velocity is calculated as average output from sprints so far. Personally, I adjust velocity calculation with the following: - remove min and max values (values can be affected by holidays, vacations, etc.) - I take velocity as a range, usually in the neighbourhood of +/- 10%. - team members are often spread across projects, their performance within your project will fluctuate.

I also believe that velocity calculation and approach is groomed throughout the project: - periodically adjust user story weights examples - plan velocity targets for the next sprint (taking into account resource availability, leaves, work on other projects, etc.) - any spikes in the velocity should be investigated and lessons learned.

Answer 6

Usually Velocity is measured after 4 sprints (in the normal cases), as the team needs some time to go through the team building phases (Forming, Storming, Norming, Performing and Adjourning), and so, we measure the velocity after the team reaches the performing phase to make things more accurate.

So, in your case, I would measure the velocity as "25".