Velocity Chart Agile Scrum

The ability of agile project management to increase project flexibility and productivity is proven across industries and not just in software development. Velocity and velocity charts in agile play an important role when talking about software project management. There are numerous tools out there used by big organizations that can be used to ensure that their sprint is successful. The article focuses on discussing velocity chart agile scrum.

The following topics will be discussed here:

1. What is Velocity in Scrum?
2. Example of Scrum Velocity
3. What is Velocity Chart in Agile?
4. How to Estimate Velocity?
5. Benefits of Agile Velocity Charts
6. Limitations of Agile Velocity Charts
7. Challenges of Measuring Agile Velocity

Let’s start discussing each of these topics in detail.

What is Velocity in Scrum?

Velocity is the measure of the delivered business value by the scrum development teams. In other words, we can say that velocity is the rate at which developers deliver product value within a specific sprint. It specifies the average number of product backlog items (PBI) that have been marked as Done and converted into an increment during the sprints by a Scrum Team. 

In Scrum, the entire work that needs to be completed by the team is segregated into “User Stories”, which majorly focus on a particular functionality of the product as required by the client. The development team calculates the time as well as the effort required to develop and test that particular functionality in form of the points or numerical values for each client. The work that is done is the sum total of these points, for the user stories that have been marked as “Done”. 

Velocity is used as a key factor in the Scrum team to estimate the effort and time required by the developers to complete the work during each sprint. We can use sprints instead of weeks or days or hours to measure the work as the developers commit to completing a user story within a specified sprint. When a particular team starts using Agile, they can decide the length of their sprint, which will be dependent on the project size and complexity of the business requirement.

• The purpose of the velocity is to predict the product backlog timeline
• A team that is able to achieve higher velocity means that team is able to deliver greater product value as well as more software functionality.
• Story point estimation will be done in the sprint backlog grooming meeting
• Story points weights are subjective to each individual team 
• Velocity is not a productivity metrics
• Velocity should not be compared between the team

Example of Scrum Velocity

Let us suppose that the development team has planned to complete three user stories P, Q, and R for finishing work in a specific sprint. The story points of P, Q, and R are  6, 5, and 4 respectively. 

• On the final day, user story Q  is 85% done, while P and R are 100 % completed and are marked to be done. 
• While measuring the total story points, the team will consider only those story points that are 100 % complete in the calculation of velocity. 
• So, here team will be only considering the story points of P and R as they are completed, while Q should not be considered and moved to the next sprint.
• Summing P and R gives us 6 + 4 = 10 points which will be the velocity of one iteration. 

Using this calculation, we can evaluate how many more iterations will be required to finish the given work.

3 Stories to complete P, Q, and R

Story Points
P = 6
Q = 5
R = 4

Percentage Completion
P = 100% (Marked as completed)
Q = 85%
R = 100% (Marked as completed)

Velocity of one iteration = Sum of story points of completed user stories
= (P+R)
= (6 + 4)
= 10

Let us assume there are another 40 story points to be done and the velocity remains the same, then we can easily compute that the same team will be requiring 40/10 = 4, more iterations to complete the given work. 

What is Velocity Chart in Agile Scrum?

A velocity chart is a graphical representation of the story points plotted on Y-axis against the sprints plotted on X -axis. 

• Using a velocity chart it becomes easy to track the measure of the effort that has been converted into an increment during each sprint. 
• Thus, it will also enable the team to evaluate the amount of effort that is required in order to complete future sprints.
• A team that has completed various iterations, will be able to forecast the release of the business product and will be able to gather information to plan upcoming projects with accurate timelines.

Now, let’s read a velocity chart with the help of an example. 

1. In the chart we can see that 38 story points were completed in sprint 1 as well as in sprint 3, 28 story points were completed in sprint 2 and 39 in sprint 4. 

2. As we already know that the story points that were completed 100% and marked as “Done” can only be considered while calculating the velocity. And even if 99 % of the work is done and only 1 % is left to be done, then also that story point will be moved to the next sprint.

3. Let us calculate the average story point that will also be the velocity of the scrum team 

Average story point = ( 38 + 28 + 38 + 39 )/4 
= 36 

Average Velocity of the scrum team = 36 

4. Now, since we have calculated the average velocity, it becomes very easy to evaluate the time required to finish the final business release.

How to Estimate Velocity?

Below are the steps to estimate velocity: 

• Capture the total number of story points completed in the past 3 to 5 sprints.
• Consider only those story points that are 100% completed and marked as “Done” and not all the story points that are planned in the sprint.
• Take the average of the story points. 
• This average story point is the velocity of the scrum team.

Example:

If the team completes the story points in the past 3 sprints are 28, 32, and 30.

Average story point = 28 + 32 +30 
= 90 / 3 
=  30
Thus, Velocity of scrum team is 30.

With the help of velocity, it becomes very easy to calculate how long will the team take to finish the final product release. 

Benefits of Velocity Chart

• Estimates time to complete work done efficiently: Scrum velocity helps to estimate how long will it take to finish the entire product backlog items for the scrum team. 
• Roadmap for a sprint: Scrum Velocity helps the product owner to plan a roadmap/release plan for a sprint.
• Helps in understanding the limits of team members: Helps the team to understand their limits while defining the amount of scope, that a team can commit for a sprint.
• Avoid over or under-commitment of the sprint: Velocity can be used as a reference in the sprint planning, to avoid the over-commitment or under-commitment of the sprint goal by the team.
• Determining the number of iterations to finish work: Calculation of velocity will help the scrum team to determine the number of iterations required to finish the given work in a particular sprint. This will also give us an estimate of the capacity as well as capabilities of the developers in the team.
• Identifying issues earlier: We will be able to find any problems that the scrum team is facing which are hindering their progress. Identifying their issues at an early stage, helps the teammates to resolve that and ensure it does not get in the way of progress.

Limitations of Velocity Chart

• Fluctuation of velocity due to multiple factors: If there is any change in scope or requirements or the number of developers, then the calculation of velocity will be impacted.
• Velocity cannot be compared between the teams: The velocity of different teams working on different projects cannot be compared, as it depends on the duration of the sprint as well as the size of the project.

Challenges of Measuring Agile Velocity

• Sprint Length: Scrum team is seen struggling with the sprint duration, this is due to slow progress on the developer’s side or some mistake in the calculation of sprint length, or some unknown issues in the team.
• Urgent Bugs: If some urgent bug pops up that hinders the proper working of the product, then that needs to be resolved on higher priority by the developers during a sprint, this gives them less time to complete the user story given to them, leading to issues in the estimation of velocity.
• Change in the number of team members: In case, new resources join the team or the older ones leave then this will cause the calculated velocity to fluctuate.
• Sudden Change of requirement: In case of a sudden change in scope or requirement of the product release, velocity will be impacted.
• Unavailability of Product Owner: If the product owner is not actively participating in the teamwork and giving his inputs properly then the team will not be able to proceed with the release in an appropriate way .