The illusion of growing velocity
In Agile, and more particularly in Scrum, velocity is often seen to be a key indicator for measuring a team’s performance. A continuous increase in this metric is generally welcome as it gives the impression of growing productivity. But this perception is misleading. Why can an increase in velocity, often seen to be progress, hide an Agile team sliding off course? Why could this even indicate underlying problems within the team, or even the company? Even though a gradual increase can sometimes be a sign of beneficial progress, through this article we will dismantle this misconception and explore why increasing velocity is not necessarily a sign of success.
1. Velocity
a) A tool, not an aim
Velocity represents the number of points of effort the team succeeds in delivering in an iteration. Points of effort are a relative measure used to estimate how complex or uncertain a task is, not its workload or the time required to complete it. This indicator mainly helps future iterations to be planned based on a probabilistic model: the assumption is that the team’s future performance will be relatively close to its past performance, even if unforeseen events occur, ratio being made of eventualities already known (absences, etc.).
However, it is crucial to remember that velocity has never been designed to be a measure of performance or efficiency. High velocity does not automatically mean that the team is more productive, that the work delivered is of better quality or that more value has been provided for users. This is a common confusion, where speed, productivity, delivering on commitments and delivering value come together. Velocity only measures an internal workflow, without directly reflecting the impact or relevance of the delivered product.
It is also important to note that the word “velocity” does not appear in the Scrum Guide, the reference document for Scrum teams. The guide prefers to refer to “past performance” to help the team estimate what it can produce in the future. This distinction is important: Scrum focuses on transparency and continuous improvement through a probability-based model, rather than searching for figures that are sometimes misinterpreted or misused.
b) The common error
The common error is to believe that increasing velocity reflects better productivity. This confusion can push teams to “inflate figures”, often to respond to pressure – real or perceived – from their hierarchy, or simply to “please” stakeholders. Unfortunately, this can be to the detriment of the team’s well-being or the quality of the delivered product.
It is also important to remember that velocity is an internal measurement for the team. If an organisation doesn’t need foreseeable predictability – for example, if priorities change frequently or needs are unpredictable – then velocity becomes unnecessary. This underlines that this indicator is above all an adjustment tool, designed to help the everyone on the team to get to know each other better and anticipate their capabilities.
Finally, a vital warning: an obsession with figures can take an Agile team away from its true mission. The goal should never be to “boost” velocity, because high velocity makes no sense unless it has a positive impact on end users.
2. Possible causes increased velocity
a) Artificial increase in estimates
Under the pressure of figure-focused management, or by misunderstanding expectations, a team can be tempted to systematically overestimate task complexity. This practice artificially increases velocity, giving the illusion of progress, but without any real improvement in productivity or delivered value.
This behaviour may arise from a need to show “visible results”, but it distorts the primary usefulness of velocity. Instead of being tool for reflection and continuous improvement for the team, it becomes a mere figure to meet external expectations. This can lead to detrimental consequences: loss of trust within the team, misalignment with user needs, and gradual erosion of transparency.
To avoid sliding off course, it is crucial to remember that velocity is not an objective in itself, but a simple indicator intended to calibrate the team’s workflow. Manipulating or forcing this figure risks losing sight of an Agile team’s true purpose: delivering value in a sustainable way that is aligned with users’ needs.
b) Excess workload
To illustrate this idea, imagine a glass of water. The glass represents the team’s capability and energy, while the water symbolises the workload. When water is poured into the glass, there’s a natural limit: when it’s full, anything else overflows. Similarly, it is not by adding more and more work to a team that it will be able to “increase” its energy level. Just like water overflowing from the glass wastes resources, an excessive workload only exhausts team members.
This metaphor highlights the importance of controlling the workflow. It is essential to focus on the ability to complete the tasks engaged efficiently, rather than just starting more. A team that accumulates ongoing tasks without being able to complete them quickly sees their efforts disperse and lose efficiency. This dispersion creates an illusion of productivity (many elements “in progress”) but does not generate any real value for end users.
Teams that give in to pressure and take responsibility for more and more tasks in an iteration are at risk of quickly reaching their physical and mental limits. This often leads to disastrous consequences: burnout, lower morale, lower quality or an end product that does not meet users’ expectations.
To avoid this, it is crucial to focus (scrum value) on a single goal and maintain a sustainable flow, where priority is given to the value actually generated rather than the mere volume of tasks completed. After all, it’s not the size of the glass that matters, but what the water poured into the glass will enable us to do.
c) An unsuitable estimation scale
Sometimes, an increase in velocity can be explained by backlog elements not being divided appropriately or an unsuitable estimation scale. For example, if the team estimates technical tasks rather than needs, or bases their estimates on time rather than uncertainty, the figures obtained may be unstable or even inconsistent. An iteration filled with “quick” tasks can then artificially exaggerate velocity without reflecting the energy the team actually needs to meet different needs.
This can be corrected by estimating functional needs rather than technical tasks or by adjusting the estimation scale. For example, comparing backlog items with each other rather than estimating them separately allows for better calibration, reduces estimation effort (which does not create value but serves predictability) and avoids biases related to ambiguities between estimated time and schedule constraints. This helps the team to focus on what really matters rather than a mere volume of tasks completed: prioritising function value, maintaining a smooth workflow, and ensuring each iteration contributes to product goals.
d) Long-term optimisation: the positive nuance
Conversely, a gradual and sustained increase in velocity can be a positive sign. If the team learns to collaborate better, optimise their processes or remove blockages, then the increase in velocity reflects a natural evolution of its maturity. For example, a better understanding of business expectations, smoother communication between team members or the automation of certain repetitive tasks can help improve the pace of delivery.
Nevertheless, this increase should be seen as the result of healthy momentum and not as a goal to be achieved. A team that focuses on continuous improvement – refining practices, increasing transparency and limiting sources of waste – will naturally be more efficient over time. However, it is crucial not to lose sight of the fact that this increased velocity alone does not guarantee the value of deliveries. As such, product quality, user satisfaction and achieving business objectives must always be the priority. Velocity, in this context, becomes an indicator among others to understand team dynamics and adjust forecasts, but it should never override these fundamental priorities.
3.The dangers of misunderstood increase
Velocity that increases without reflecting on its causes can lead to several major risks, which are often underestimated:
- A decrease in product quality: Going faster often means sacrificing rigour in design, execution or testing. In practice, this results in an explosion of technical debt and deliveries potentially full of bugs. Tests are generally what teams pass on, compromising product reliability and, user satisfaction in the long run.
- Overload and exhaustion: The constant pressure to “do more” pushes teams beyond their physical and mental limits. While this dynamic seems to work in the short term, with a temporary increase in velocity, it inevitably leads to burnouts, people leaving, internal conflicts and people largely feeling demotivated. This is a type of event that cannot really be considered a success.
- Loss of focus on the function value: When velocity becomes an end in itself, the primary goal – solving user problems and delivering value – becomes secondary. The figures then take the upper hand over empirism, pushing teams to look for a “perfect” solution rather than a suitable one. This incorrectly assumes that user needs are fixed and everything is predictable, while the market, users and competitors are constantly developing. This is a good example of Goodhart’s law: ‘When a measure becomes an target, it ceases being a good measure’.
- Team dynamics are weakened: An obsession with increasing velocity can harm team spirit by encouraging competition between teams at the expense of collaboration. It makes no sense to compare the velocity of different teams. Even worse, measuring it individually is a ridiculous and counterproductive practice that ignores the importance of mutual support and collective work. This leads to tasks being individualised tasks and internal competition within the team or the company. The aim should be to strengthen cohesion and collective dynamics rather than focusing on isolated performance.
Praising an increase in velocity without questioning its causes equates to anchoring bad practices. In the short term, this increase may give the illusion of progress, but it often comes at the expense of quality, well-being and added value.
Robert C. Martin, one of the signatories of the Agile Manifesto, sums up this idea well: “Don’t put pressure on the thing you are measuring. Search for the root cause while you continue to measure. Otherwise you hide the very problem you are trying to solve”
Sustainable pace – one of the principles of the Agile Manifesto – must remain a priority. A team that progresses at the right pace, with a constant focus on quality and value, will build lasting success, not short-lived performance. Good velocity is not velocity that increases, but velocity that is constant, indicating that the team is predictable and controls its production rate.
4. What to measure instead
Rather than focusing on velocity, it makes more sense to rely on more relevant and comprehensive indicators to assess the success of an Agile team, such as:
- The value actually delivered,
- The impact on users,
- The ability to deliver quickly
- The product’s technical quality
- The team’s well-being, ensuring a healthy work dynamic that motivates
These elements highlight what really matters: creating a product that is not only of quality, but also useful, usable and used.
This framework can be strengthened by using Evidence-Based Management (EBM), an approach that proposes fact-based management based on concrete indicators to measure performance and impact. EBM distinguishes four key areas, called Key Value Areas (KVAs), to measure what really adds value:
- Current Value: Measure the value that the product delivers to users, stakeholders or the organisation today.
- Unrealized Value: Identify future opportunities and potential value that has not yet been exploited and may therefore justify additional investment
- Ability to Innovate: Assess the capability of the team and organisation to deliver new features or meet emerging needs.
- Time to Market: Measure how quickly an idea or feature can be designed, executed and delivered.
These KVAs provide a framework to guide strategic decisions, aligning efforts with tangible and measurable goals. This allows teams to focus on delivering a high added value product while balancing innovation, quality and sustainability.
Conclusion: Is increasing velocity a warning or an opportunity?
Velocity, although used by most Scrum teams, is just one indicator among others and should never become a goal in itself. It can be useful in estimating the future capabilities of the team based on past performance, but over-focusing on this measurement can harm product quality, team health and value actually delivered. Rather than seeking to “inflate figures,” it is crucial to prioritise indicators that measure what really matters: business value, product quality, team engagement, and user satisfaction.
The Evidence-Based Management (EBM) framework provides a more nuanced and comprehensive view of performance by focusing on indicators such as current value, capability to innovate, or time to market. These dimensions make it possible to truly assess what makes the difference for users and stakeholders, while maintaining a sustainable, motivating work dynamic for the team.
In the end, the ultimate goal of an Agile team should be to deliver a product that is useful, usable and used, not just to increase a figure. Velocity must remain a reflection of the team’s internal dynamics, but never an end in itself. A variation in velocity, whether it is upward or downward, must be analysed retrospectively and not interpreted in a simplistic way. An increase in velocity can be a warning about a potential dysfunction, rather than a sign of success: it could indicate excessive pressure, lower quality, or bypassing best practices.
Similarly, a decrease in velocity is not necessarily a bad sign. It can reflect a cultural change within the team: the shift from a logic focused on ‘producing more’ to a willingness to ‘produce better’. This often reflects a deliberate decision to slow down to focus on quality, collaboration, and responding to real user needs. This type of controlled slowdown demonstrates increasing maturity, an ability to adapt to the requirements of the context, and stronger alignment with the fundamental goals of an Agile team: delivering value, meeting user needs, and maintaining team balance.
