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.

Why is increasing velocity very likely bad news?

How the VOC addresses, prioritises, and fixes vulnerabilities