Workflow Platform for all kinds of business process and approvals
Velocity in agile is an important metric that helps the team improve efficiency by determining how much it can achieve over time. After every iteration, the team adds up effort estimates associated with user stories that were completed. In project management, this helps in determining how long it will take to complete the project.
Velocity in agile is a measure of how much work an agile team can deliver on average in a sprint.
It takes a view at measuring:
With this in mind, the agile team and its stakeholders can accurately estimate the agile team’s capacity, i.e. how much work they can achieve in a specific duration, i.e. in a sprint.
In essence, velocity in agile offers agile teams a way of calculating how fast they’re getting work done, and as a result, how many sprints will be required to get a project to a certain degree, and overall, create significant change.
Like we’ve established, the need for agile velocity arises from wanting to know how fast an agile team can iterate and deliver features that incrementally develop the project. There are several factors that come into play when determining how fast an agile team can deliver.
How long is this sprint going to last for? How long do we have to deliver our outlined workload? Is it feasible based on previous sprints?
Velocity in agile is a fairly simple concept to calculate. All you have to do is measure the total amount of backlog items that were delivered per sprint.
As the team runs through more iterations, you can determine an average amount of backlog items, or ideally, a slim range of backlog items or features the agile team can deliver per sprint.
Velocity makes it easy for agile teams to estimate how much work they can achieve per sprint and how long it’ll take to get a project to a certain level of growth.
Agile velocity is measured in either days, ideal days, or the number of hours it takes the team to deliver a number of backlog items, story points, etc.
Here are some frequently asked questions about agile velocity:
Divide the number of backlog items or user story points that’s been delivered during the course of several sprints by the total number of days in those sprints.
It is not, it is estimated or more specifically, projected.
Initially, it might be difficult for an agile team to estimate the amount of work that can be delivered in their first iteration. A good experimental estimate is to allocate just 30 percent of the work to that initial sprint.
For example, if a sprint is projected to last 2 weeks, with 6 teammates working on the target items identified, the total capacity available equals 84 days (expert-days = 7 days * 2 weeks * 6 experts).
The team should plan out 28 expert-days of work for this two-week sprint, with lots of buffer time for the team’s auxiliary needs like answering calls, writing emails, cross-team needs, unforeseen circumstances, etc.
With the results from this initial sprint, the agile team can watch whether they exceeded or performed below expectations and adjust gradually before there’s enough data to determine how fast they’re moving.
Ideally, velocity in agile should be localized only within a team.
Because across other teams, several variables come into play. Other teams may perform different work, have different staff count, or have different strategic targets.
But in a situation where much of the teams within an organization do cross-functional work, agile velocity can be calculated for individual teams as well as adjusted organizationally as the need may arise. This mostly because teammates and resources can be moved from lower-velocity teams to where higher velocity is needed.
If agile velocity fluctuates within a safe bracket, the agile team might have to analyze to pinpoint what’s changing and how to address it. In the bigger picture, widely varying agile velocity may affect bigger picture project targets and require changing deadlines, adjusting plans etc.
When agile velocity fluctuates, the agile team should find out what changing data point or situation led to it and address it—as long as no other significant part of the project is affected adversely.
Otherwise, under normal circumstances, agile velocity stabilizes within 3 – 6 iterations.
The aim of measuring agile velocity now is to make it easy to accurately estimate future agile velocity. So, to estimate future iterations, apply the range you’ve arrived at over previous sprints —assuming no significant factor has affected the team’s productivity.
All things being equal, changing an agile team’s size will affect the volume of work it can deliver.
A good formula is to alter a coming sprint’s expected velocity by the number of resources that’s been removed from the agile team. If a staff that contributes 10 expert-hours (team size * number of hours in the sprint) of input out of 40 expert-hours per sprint, removing that staff from the team would require reducing the team’s velocity by at least 25% to match the drop in capacity.
More than just a shiny metric that shows how long on the average it takes an agile team to run through sprints, velocity in agile is indispensable to growth-focused agile teams looking to scale iterations faster.
For example, by looking at an agile team’s velocity, it can be determined that adding extra team members and resources can increase team productivity, making it easier to run through sprints, i.e. deliver target items faster.
On the other hand, an agile team that’s running faster than is required for the entire organization can have its resources safely redirected to other teams operating at a lower velocity.
It all works hand in hand. And because of that, velocity isn’t a metric you can afford to overlook within your agile strategy.