Velocity in Agile Projects

This article talks about calculating the team velocity of the agile project and addressing the benefit of the team velocity.

Velocity is an extremely simple, powerful method for accurately measuring the rate at which teams consistently deliver business value. 

It is a measure of how much product backlog items the team can complete in the given amount of time.

It is used the compare the iterations for the given team on a given project, the note is only completed work counts for calculating the velocity.

For example the testing planned with the in the sprint and one of the story failed in testing and required more effort to fix all the issues, which goes beyond the sprint. This story will be dropped from this sprint/iteration. This story will not be counted for the calculating velocity.

 Some of the benefits of velocities are:

·        Understanding about agile project performance

·        Reporting project progress, productivity, predictability

·        Finding pain points and improvement areas

·        Used as metrics

·        Calculating the rate at which the product moving forward

·        Provides vision what can be achieved in next release

The team velocity is calculated based on the completed story point. I will write another article to explain the story point estimation.

In simple terms, a story point is a measure of complexity. This is to differentiate it with hourly estimates, which are a measure of effort.

The second idea is that story points are a relative measure. That means we choose one user story and keep it as the reference and assign it a value of 1 point. We then measure every other story relative to this one. So if the second story is twice as complex, we give it a value of 2 points. Thrice as complex and it gets 3 points and so on. Go through the entire backlog this way.

The story point can be mapped to the effort, for example to complete development of 1 point takes 4 hrs. This is used as the reference, but the effort will vary the person who implements it.

Velocity is a vital component of iterative planning. To see how it is used, consider this example:

1)    A team reviews a release backlog with the product owner, and estimates the relative sizes of user stories in units of story points (one story might be sized at 3 points, another at 1 point, etc.). The release backlog, when estimated, totals 120 story points.

2)     Over the course of several iterations, that same team has demonstrated that it consistently delivers between 18 and 22 story points per 2-week iteration, to an agreed definition of “done”. It therefore considers its velocity to be approximately 20 points per 2-week iteration for planning purposes.

3)    Based on a total backlog size of 120 points, and a velocity of 20 points per 2-week iteration, it can be determined that it will take this team 120 divided by 20, or a total of six 2-week iterations (12 weeks) to deliver the entire backlog.

4)    If the product owner has a hard delivery date commitment that will only allow 8 weeks for the release, then they will only have four 2-week iterations to work with, and will have to decide which 80 story points worth of stories ([8 weeks /2 weeks = 4 iterations] * 20 story points per iteration) are the most important.

So in the case above, size is estimated, velocity is measured, and duration is derived.

The below velocity graph shows the team velocity of the given project, when we look in to the story point completed per iteration is not stable, as mentioned above we need to make the necessary improvement actions this will help the team to stabilize the project in 3 to 6 iterations.

The Control Chart below shows the iteration velocity that tracks the story point’s completion per iteration. It is the good indicator of productivity throughput and the tolerances can be used for the investigation, if it drops below the lower limit.

Based on the historical data of the project the UCL, LCL and the Mean value are calculated. This is used for the finding the improvement areas.

Kindly note that keep on increasing the team velocity is not mean to maximize the productivity, when we focus more on increasing the team velocity the team may skip following standards, unit testing, bug-fixing. The goal is to maintain the optimum velocity over time, which takes account of following standards, quality and other factors.