Agile is one of the commonly used Software Development methodologies for its ability to facilitate cross-team collaboration and ensure successful projects even when the business requirements are very dynamic in nature. Scrum is one of the most widely used Agile flavors which focusses on Project Management practices and inculcates many of the behaviors you see in Scrum teams today such as Stand ups, Sprint Planning Meetings, Sprint Reviews etc. There are many important metrics that are typically used by Scrum teams to measure progress and manage projects such as sprint burndown, sprint goal completion, team capacity to name a few and Scrum Velocity is one of the critical metrics.
Scrum velocity is a fundamental yet a highly controversial metric, as several things can go wrong with the said metric. Many organizations use it diligently, while others still debate about the extent to which it should be tracked. It indeed has its set of benefits but also has noteworthy pitfalls that can make you focus on the wrong thing.
But what is scrum velocity, and how can it go wrong? Let's begin.
What is Scrum Velocity?
In simple terms, scrum velocity is the amount of work a scrum team can do in a specific time period. It is the capacity they have for achieving a given purpose, and for producing a useful and quality working software. Usually, scrum velocity is calculated at three levels:
- Cycle Time, where scrum velocity represents the time the team takes to complete user stories.
- Sprint Level, where scrum velocity shows the number of story points completed by a team per sprint.
- Release Level, where scrum velocity tracks the extent up to which the team has met the initially planned scope of the release.
How to calculate velocity in scrum?
Scrum velocity has two versions but calculations for both versions are similar. Actual velocity is calculated by dividing the total Story Points completed by the team by the number of Sprints. This version is more accepted by Scrum Teams and used commonly during velocity calculation.
The second version of scum team velocity is known as the expected Velocity where the total estimated Story Points are divided by the number of Sprints. Here, the team estimates the Story Points that it may complete in a given number of Sprints. This version is not used frequently but may be used to compare with the actual velocity so that the Scrum Master could see whether the team meets up with their commitments.
As scrum velocity is calculating the capacity of a team to achieve the given purpose and in how much time it is being achieved, several things can go wrong with it.
What Can Go Wrong with Scrum Velocity?
1. Setting Velocity Targets
Agile velocity is meant purely as the metric that can be used for a scrum team's estimation, rather than an empirical measure of a team's progress. However, businesses can get too invested in the metric and actually set up velocity targets or goals. This is where things can go extensively wrong.
Velocity targets can be misleading, especially when they are used as a metric purely for tracking a team's progress. Although velocity is in the scrum team's control, it becomes a variable of paramount concern to the management when treated as a target. Even worse, when this metric can be used to penalize the team for not achieving. Tracking Metrics are important but what is more important is to understand the underlying cause and fix the issues.
Aiming to improve scrum velocity is not wrong. It can be done over time, supported by the enhancement of the team's scrum process, removing bottlenecks, and addition of new tools for increased proficiency. However, setting quantitative velocity targets is a defective approach to refine scrum velocity.
2. Using Velocity to Compare Teams
Different teams work at different speeds, handle projects of varying complexities, and even consist of members with varying skill sets. A lot of factors influence how well a team does in a specific period of time. So, comparing teams purely on velocity is unfair and impractical.
If scrum velocity is being calculated at the sprint level, the concept of story point estimates being subjective is ignored. Additionally, the system can be manipulated by developers, giving certain teams the undue advantage of showing better scrum velocity than others.
Comparing teams using scrum velocity sets the foundation for cultural damage, internal conflicts, poor team morale, and deteriorating performances. Using it to navigate situations within one team should be the approach. Still, it is easy to get trapped in this pitfall and one that you should avoid at any cost.
3. Unfair Expectations of Instantaneous Maximum Velocity
Every team requires a certain timeline to start performing in a cohesive fashion. With new scrum teams, members require time to adjust to each other's working styles along with understanding the new application. With old scrum teams, members need time to figure out the new complexities, adapt to the different dependencies, and create action plans.
Expecting teams to achieve maximum velocity instantaneously is wrong, especially since leaders are building expectations based on an outsider's perspective. Only the scrum teams and managers can actually estimate true scrum velocity, as they are the ones working with the ground realities. Several complexities and internal roadblocks can only be understood and resolved by the people working with the project and not by anyone working outside of it.
Scrum teams require time to mature and realize their full potential. Allowing them the space and time to figure out their cadence is essential. Business leaders who don't figure this out end up harming their team's ability to come together & progress in the right direction.
4. Giving No Slack Time
Every scrum team needs time for communication, problem-solving, and addressing unplanned items. Such time decreases scrum velocity, alarming managers to do something about it. As a result, slack time gets removed or extremely limited, making processes inefficient and problematic. This results in the teams focus to only deliver and not on delivering high quality solutions.
However, it is crucial to understand that removing slack time will ultimately decrease scrum velocity even more in the future as team members have no room for important huddles and to recharge the social contract. The focus shifts from doing tasks effectively to completing them within the set time frame. Quality will get compromised, hurting overall business success.
Such extreme focus on keeping scrum velocity high can harm the business significantly. Giving slack time is essential, but giving too much importance to velocity drives leaders to choose the other way around.
5. Lack of Investment in Quality
Scrum meetings that focus majorly on scrum velocity risk the chance of lacking investment in quality. A scrum team should apportion time for unplanned activities like critical bugs that get notified by customers, infra downtime, addressing technical debt etc to name a few.
All these activities are essential to provide solutions of higher quality and require investments for necessary resources to be leveraged by scrum teams. Without such investments, the quality of final product deteriorates, and problems for future timelines increase. The project suffers, and ultimately scrum velocity is impacted as well.
It is necessary to think of the long run and invest accordingly. With a complete focus on scrum velocity, things might move faster, and teams might be able to achieve effective results in the short run. However, it is bound to create more problems in the long run and impact progress negatively.
6. Using Scrum Velocity to Determine Project Completion Timeline
Using scrum velocity to estimate the precise completion of a project is an inappropriate practice and goes against the Agile principle, but unfortunately, several scrum teams are led by leaders that implement this thought process.
Several factors influence scrum velocity. The basic idea behind scrum development consists of frequent changes in requirements, short development sprints, and changing variables. Measuring its progress with a static measurement tool or metric is a poor choice, primarily when the said metric can only provide an approximation rather than a precise timeline.
Scrum velocity can indicate an approximate timeframe in which a project can be executed, and that is precisely how it should be treated. The possibility of scrum velocity being an inaccurate predictor of future timelines must be considered, and planning should be done accordingly. It can be a terrible metric when used to determine the project completion timeline.
Planning accuracy is essential at the beginning of every new project, and scrum velocity of the past projects is not the right metric for the same. Additionally, it can prove to be a terrible measurement of team productivity and efficiency if used to compare two teams.
How to Increase Scrum Team Velocity:
- Use Cross-training: Ensures that the knowledge transfer is consistent
- Avoid context Switching: Allocate each team member to one task at a time
- Resource Management: Be aware of resource management and maintaining a constant development team
- Avoid Cross-Team Comparison: Do not compare velocity across different teams. Each team organically develops their own velocity.
- Standardize you Measurement: Use consistent definition of done across your sprints. Use a rolling average of the last 3-4 sprints to plan the next sprint. Remove any anomalous outliers to obtain a better average.
Today, agile is a popular software development methodology and scrum is one of the widely used Agile flavors – Scrum velocity is arguably one of the most popular metrics tracked. Its use for capacity planning is unparalleled, and its benefits are many. However, when leaders or management begin to use the said metric for anything other than capacity planning, things go downhill, and scrum velocity becomes a dangerous metric.
Scrum velocity, calculated at any level, must stick to its purpose. Things go wrong with it when people make inappropriate use of it. Using it to compare different scrum teams, developing unfair expectations about instantaneous maximum velocity, giving no slack time to teams, lacking investment in quality, using scrum velocity to determine project completion timelines, and setting velocity targets are some of the many things that can go wrong with it. Implementing the right practices and using scrum velocity for what it is meant for is necessary to ensure that the said metric remains positively helpful and does not impact the business or scrum teams in a negative way.