The ability of Agile project management to increase flexibility, productivity, and high-quality deliverables is proven across industries, not just in software development. Agile is often used in a Scrum framework, and one important metric used is velocity. This article will explain what velocity is in Agile and show how to use it to predict project completion.
The rate at which your team can deliver is a key Agile metric, called velocity. Accurately calculating your Agile team’s velocity will allow you to determine the dates you can reach product milestones or, if you need to deliver a product in completion, what date you should be able to achieve completion. Velocity will also help you avoid overpromising on deliverables for a client.
Agile velocity is a useful tool for teams to use internally, not necessarily to use for external determinations. The team can use it to track estimates and completions over several sprints—giving them an accurate understanding of how fast they can move through a backlog. It helps a team look at their progress and strengths and learn how to improve their metrics.
Before you begin to calculate your team’s velocity, you will want to complete at least three to five sprints. This allows for a team that is new to Agile project management to get used to the workflow and for any changes the team is going through to normalize. Your velocity will fluctuate during these initial sprints but will stabilize after three or more have been completed.
The rule of thumb in determining a story point is to find the simplest story, assign it one point, and then use it to assess the rest. You can use two scales to determine your story points: a linear scale or Fibonacci sequence.
To calculate the velocity of a sprint, you need to know how many user stories the team needs to complete. You also need to know the number of points that a user story is worth. Then, look at the number of stories completed and add up the points.
Let’s look at an example of velocity in Agile:
In sprint one, your team has committed to eight user stories, and each story equals three story points. Let’s say the team only completes four stories. You would achieve 12 story points in total.
In sprint two, your team has committed to 10 user stories, and each story equals five story points. Let’s say your team completes seven stories. You would end up with 35 story points.
In sprint three, your team commits to nine user stories, and each story equals four story points. Let’s say your team completes seven stories. You’d have 28 story points.
Now that you have the individual sprint velocities, you can average them together.
Average sprint velocity = (12+35+28)/3 = 56
Once you have found the velocity of each sprint, you might want to enter that information into a velocity chart. A velocity chart can help in a few ways:
It can be used to track the status of a project.
It can be used to track volatility, which is a measure of predictability. If you are finding hills and valleys in your chart, the project is an unpredictable one. That can be for several reasons, including the size and difficulty of the project and team changes.
A velocity chart will also help you identify patterns in your team's velocity — including on projects where there may not be story points, but instead, the team is working out bugs.
Let’s look at an example of how to calculate velocity and predict project completion.
Assume your team committed to four stories, and each story is worth four points. At the end of the sprint, your team has completed three stories, but the fourth is only half complete. In Agile, you don’t count partially completed projects—it’s all or nothing—so you want to calculate only the three completed stories. Your velocity on this sprint is 12.
In this step, you want to assume that your remaining sprints will be similar. Your team can now revise the prediction of when the project will be completed. With this in mind, let’s assume the project includes user stories that total 48. To complete the project, you will need a total of four sprints.
Remember that there is no ideal velocity number. By following the processes outlined above, a project manager can use velocity in Agile to determine the number of sprints that will be needed for the project and how much time each sprint needs.