VELOCITY – STORY POINT IS NOT ENOUGH!
Although not explicitly described in the Scrum Guide, velocity remains a commonly used measurement element within teams implementing the Scrum framework.
Traditionally measured in Story Point, this metric is widely used to evaluate how quickly and efficiently a development team delivers its features.
However, this traditional view of velocity, although useful, can be reductive and counterproductive.
In this article, we’ll explore why it’s crucial not to limit our understanding of velocity to Story Points alone. We will see how this metric, although central, only captures one facet of a team’s overall performance.
What is a Story Point?
A Story Point is a unit of measurement used to estimate the effort, complexity and risk associated with producing a “user story” (a specific functionality or need for the product).
Unlike hours or man-days, Story Points are abstract and relative.
They allow requests to be compared with each other. For example, a request rated at 5 Story Points is considered to require more effort or be more complex than one rated at 3 Story Points.
How to measure in Story Point?
To estimate Story Points, many teams use the Fibonacci sequence (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, …).
This sequence is chosen because the increasing gap between the numbers reflects the increasing uncertainty and complexity of estimates for larger tasks.
Estimation process
During the Iteration (Sprint) planning sessions, the Developers evaluate each user story by assigning it a number of Story Points which reflects their estimate of the necessary effort, via a session called “Planning Poker”. For example, a task deemed twice as complex as another will receive double the number of points.
Benefits
Using the Fibonacci sequence helps prevent false precision. It reflects the fact that the larger or more complex a job is, the more difficult it is to accurately predict the time required to complete it.
Story Points help teams plan their sprints and prioritize tasks. By better understanding the effort required for each task, the team can better organize and manage their time.
Measuring the effort required also makes it possible to better divide the activities to be carried out, so that each can be processed during a Sprint.
Over time, the team becomes more precise in its estimates, which improves the effectiveness of sprint planning.
What is the problem?
Story Point measurement, although popular in Agile approaches, is not without its drawbacks and can lead to perverse effects if it is misunderstood or misused.
Excessive Focus on Points Rather than Value
Teams can focus on accumulating Story Points rather than delivering real value to users.
The objective no longer becomes “How to create more value”, but “how to always create more Story Points” (note: We will see later how to move to velocity through value).
Compare velocity between teams
The Story Point being a relative unit of measurement, representing the effort to be made estimated by the Developers, can vary from one team to another. 2 Story Point for team A may not represent the same notion of effort as for team B.
One of the constant mistakes that some organizations make is to want to make the Story Point uniform and to compare the performance of teams with each other, which results in unreliable comparisons, a poor understanding of the objectives of the Story Points and unnecessary pressure on the teams. teams that can lead to abuses, such as artificially increasing estimates in order to please management.
Stress and pressure on Teams
Waiting for delivery based on Story Points can create unnecessary stress. Sprints can become a race to complete Story Points, leading to exhaustion and a drop in quality.
Hijacking Agile Goals
An obsession with Story Points can lead to neglecting the agile principles of flexibility and adaptation to changes, making them a rigid management tool, particularly when the Story Point is systematically converted into man-days or/and distributed over the number of team members making up the Developers (e.g. often seen during my support: A Scrum team has 52 points on average, for a team of 5 people, that is therefore 10.4 points/person. If a person is absent, the management (or the Scrum Master. …and yes, it happens) will remove 10.4 points from the team’s ability to perform. We can clearly see that this type of measurement is not consistent because it does not take into account the seniority of the each team member, there is because the Story Point remains a relative estimate of an effort to be made and not an exact value of duration or skill.
Difficulties in Long-Term Forecasting
Due to their relativity and variability, Story Points are not always a reliable indicator for long-term planning or project deadlines.
Lack of understanding from external stakeholders
Stakeholders unfamiliar with Agile may misinterpret the meaning of Story Points, treating them as concrete units of measurement.
Some organizations may even define the Story Point as the unit of measurement for a team’s productivity.
Velocity must make its revolution!
Although leading to a certain amount of drift, velocity nevertheless remains an important measurement element for a Scrum team, but must be completely reviewed in its measurement and management.
Velocity belongs to the Scrum team
The purpose of velocity measurement is to allow a Scrum team to monitor the performance of its activity, in relation to the Sprint objectives which were defined during Sprint Planning.
Its objective is also to allow the team to identify obstacles, such as problems in the value creation process, resulting in a decline in their ability to deliver value and a drop in the quality of the product delivered.
But for this velocity measurement to remain effective and relevant, it must remain the responsibility of the Scrum team. No interference must be permitted by management, resulting in a deterioration of the quality of this measure and its objectives.
Measure the achievement of your objectives more than the points achieved!
The Scrum team should not base its velocity measurement solely on Story Points, which basically only aims to allow developers to estimate the effort to be made in carrying out a request.
Velocity should be closer to a measure of the team’s ability to meet its Iteration objectives.
This can notably involve measuring the business value achieved (Business Value), in relation to the objectives defined during Sprint Planning.
If you use an activity monitoring tool, like Jira, then you will just need to create a new “business value” field that you can associate with your Sprint tickets and which will allow the Product Owner to define the business value provided. by each request associated with the iteration objective.
Use Velocity to identify obstacles
One of the benefits that velocity must have is to allow you to identify obstacles that the team may encounter during an Iteration, such as quality problems.
This is why it is rarely advisable to value technical debt tickets (or anomaly) which could disrupt the team’s activity.
Let’s imagine a Scrum team measuring its velocity based on Story Points.
The velocity tracking graph, in Story Point, shows that the team is struggling to meet its Sprint commitments.
Now let’s analyze the same graph by measuring the number of tickets produced during the Sprint.
The observation is quite different. We see that the team goes beyond the commitments made at the start of the Sprint. If we only base ourselves on this measurement, then management will be very happy because the team is doing better than expected… Yeah!
However, if I now filter this graph on only anomaly or technical debt type elements.
The observation is clear: the team is systematically overwhelmed in each sprint by quality problems which prevent it from achieving its Sprint objectives.
If the anomalies had been valued in Story Point, this observation would not have been possible.
Use Flow Time to measure the quality of your estimates
As we have already explained previously, the Story Point measurement remains relative and can prove to be unreliable in the quality of the projections.
In order to validate the relevance of these estimates, you can associate your Story Points with a measurement of the average flow time necessary to process a request.
You can also measure the average processing time for requests, within a Sprint, in order to identify requests taking too long compared to the duration of the sprint, putting the achievement of objectives at risk.
Using Velocity to Measure Predictability
Predictability makes it possible to define the level of confidence that we can bring to the team’s commitment in relation to its real capacity to do so (Velocity).
For example, if a team commits to an objective of achieving 50 points of business value and at the end of the iteration it has achieved 36, then its Predictability will be 36/50*100 = 72%.
Consistently greater than 100% predictability can be a symptom of a team that is undercommitting too much relative to its actual ability to do.
A predictability regularly lower than 70% can be an alert, either of an under-commitment of the team, voluntary or forced, or of regular obstacles disrupting their ability to achieve their objectives.
Stop integrating velocity into service contracts
We still see many (too many?) IT service companies or client organizations wanting to integrate the notion of performance to be achieved in terms of Story Point velocity into their service contract. Often this injunction is accompanied by a penalty in the event of non-compliance.
All of this simply makes no sense and even goes against the interests of the client.
When you integrate velocity into Story Point as a mantra for team performance, you will create a perverse effect or, in order not to risk a penalty, the team may be led (under pressure from its management) to increase its estimate by Story Point to always stick to the Velocity required by the contract, without creating more product value.
Conclusion
The measurement of velocity in Story Points, although useful in certain contexts, has significant limitations which can paradoxically hinder the contributions it seeks to promote.
It is time to rethink our approach to velocity measurement, in order to focus more on creating business value and team autonomy.
Adopting new methods of measuring velocity, such as tracking Business Value or Flow, offers a richer perspective that is more aligned with the final objectives of product value creation.
This approach fosters a deeper understanding of the real impact of the team’s work on business outcomes, encouraging more strategic and customer-focused decision-making.
Furthermore, by restoring velocity to teams – by allowing them to define and measure their own performance in a meaningful way – we strengthen autonomy, responsibility and commitment. This allows teams to focus on what’s truly important: continuously delivering high-quality products that meet changing user and market needs.
Ultimately, by shifting our focus from quantity measured in Story Points to quality and value, we can fully realize the potential of Agile. This shift represents a natural evolution towards greater Agile maturity, where velocity is not just a number to achieve, but a dynamic indicator of meaningful progress and added value.