The Velocity metric has a rather poor reputation due to frequent anti-patterns associated with it. In this article, I describe the role of the Velocity metric in a multi-team environment, what it is not for, and how we can use it proactively to plan a release to production.
Let us start with the units we use to measure Velocity.
STORY POINTS
Before an Agile team takes a feature or user story into development, it estimates its complexity/size. The estimation unit is typically a Story Point, although some teams use their own terminology (Gummy Bears, NUTs …). Velocity
This is not only a Scrum practice; “sizing” is also used in Kanban and Scrumban, even though proponents of these frameworks like to deny it. A Kanban team typically performs sizing at Weekly Replenishment and Delivery Planning events, when members assess the likelihood that a feature will be completed in, for example, 10 days. Scrumban, in turn, uses Trigger Planning, which is dynamic based on the development pace and likewise serves to estimate the effort required for backlog items.
The purpose of estimation is:
- A discussion about features and user stories, which leads to better understanding, identification of potential issues, uncovering non-functional (backend) requirements, and removing low business-value functionality. In addition to developers, the Product Owner and, when needed, representatives of end users (who best understand the domain and expected business value) are key participants in this discussion.
- Verifying whether the team can deliver the proposed user story in the next Sprint and, if necessary, breaking it down into smaller sub-stories. This is important because the team is expected to present a product increment with some business value at the end of each iteration. Ideally, this increment is also ready for immediate deployment to production (Done). In Kanban, this threshold is typically a larger release to production.
- The team takes on as many user stories as its capacity (Velocity) allows, based on experience from previous iterations. Ideally, this is not a single large user story, because the team then risks not having a Done increment at the end of the iteration. If the team develops several smaller stories, each with its own business value, a blockage in one story will likely not jeopardize the iteration goal (Sprint Goal), and the team will still generate some business value. A typical user story should represent 2 to 3 days of work for one developer. Of course, this depends on the context.
A Story Point is a small unit of work that all team members understand and agree on in terms of its size. The size of other user stories is then estimated as a multiple of the “baseline” Story Point. Typically, we use factors from the Fibonacci sequence (1, 2, 3, 5, 8, 13, …).
Examples of a baseline (1) Story Point user story:
- Adding a login button to a web page
- A table on a web page populated from an SQL server
- Preparing a gift package for an average well-behaved child (Santa metric)
- Installing and configuring an SQL server
- A web page with 50 standalone text fields
- Eating one chocolate bar
- Displaying a GDPR pop-up on a web page
- An API query and writing a calculated value into a field
- …
The size of a Story Point is team-specific. During development, it should not change, since that would distort the metrics. Velocity is the number of Story Points the team delivered in one iteration. In a multi-team environment, there is no need to standardize the baseline Story Point across teams. The only possible reason for doing so would be the desire to compare team productivity, which is in direct contradiction to the Agile philosophy.
VELOCITY
In Scaled Agile, where multiple teams work on a shared product increment, a few questions arise due to different Story Point sizes and the associated Velocity:
- How do we plan if each team has its own baseline Story Point? The baseline (1) Story Point size chosen by an individual team does not affect planning. The team takes on as many user stories as its historical Velocity allows. The team estimates the size of a user story using its own scale. We assume that equally sized teams with similarly experienced developers have roughly the same capacity – regardless of how many team-specific Story Points a given user story was estimated at.
- How do we compare the productivity of different teams?
We do not do this in a Scaled Agile environment. A group of teams working on the same product is evaluated and rewarded as a whole.
- What, then, do we base team rewards on?
Rewards are based on the “one level up” principle. This means that individual teams are not rewarded based on their productivity; instead, the group of teams as a whole is rewarded based on the business value created. This approach encourages cross-team collaboration and the sharing of good practices and information, which is, after all, the goal of Scaled Agile practices.
- Can we predict a release date given that team Velocities are not comparable?
Yes, the method is described later in the article.
- How should we report team productivity to management?
We do not do this. For reporting, the metric is business value created. If business value declines across iterations, that is primarily the responsibility of the product manager or Product Owner, not the developers. A certain decline in business value over iterations is expected, because teams always develop the highest business-value/ROI functionality first. As we move lower in the backlog, values naturally decrease. It is advisable to stop developing new functionality before its ROI turns negative.
- What is the impact of AI on productivity in a multi-team environment?
The potential conflict that arises as a consequence of differing AI usage is described in this article.
Given the above, Velocity is therefore not:
- A basis for rewarding teams
- A team productivity metric
- An indicator of team drive
- Composed of time units
- A status report for management
- A guarantee of future team productivity
- An indicator of business value created
- An indicator of development process effectiveness
RELEASE PLANNING IN A MULTI-TEAM ENVIRONMENT
How do we forecast a release in a Scaled Agile environment given that each team uses its own definition of the baseline Story Point?
We will make the forecast using burndown charts* from which we will remove Story Point values and compare only their slopes.
* Some time ago, in anarticle, I argued that a burnup chart is a more useful tool for a team than a burndown – yet now I am promoting burndown. The claim still holds. Comparing Velocity using a burndown chart is a tool for the Product Owner and Scrum Master. It does not provide useful information to developers and could lead to unhelpful rivalry between teams.
From the chart, we can see that:
- Team C will likely complete the committed user stories before the planned release date.
- Team B is “behind” and will likely not complete the work before the planned release date.
- Teams A and D will likely complete development by the planned release date.
It appears that (given the current state) the probability of releasing on the planned date is low. We have several options.
Reduce the scope
The Product Owner meets with stakeholders and tries to reach consensus on reducing the scope of the planned release. Perhaps a few of the lowest business-value features can be removed. Alternatively, a feature can be split into two sub-features: the one with higher business value is developed for the current release, while the lower business-value feature is moved to one of the next releases. In Agile, this technique is called Value Based Decomposition.
Postpone the release date
In a company, a release is often coordinated with other related activities such as a marketing campaign, investor presentations, vacations, and the like. Given that the execution of related activities run in parallel, postponing the release date is often unrealistic.
If there are no such dependencies, or those activities are sufficiently flexible, postponing the release is a realistic option.
Reorganize the work
A third option would be to activate internal reserves. In our case, this could mean:
- Team C relieves Team B by taking on development of some of their user stories.
- One or more developers from Team C voluntarily move temporarily to Team B.
- Developers from Teams A and D can also help Team B (swarming); in the final iterations before the release, they will likely be less busy (a common pre-release situation, when the burden gradually shifts from developers to testers—not every developer is also a tester).
- Add new members to Team B from outside or from within the organization. It is important to be aware that, in the short term, Team B’s productivity will likely drop until the new members successfully integrate into the team (Tuckman’s stages).
The role of the organization and the Scrum Master is to create a working environment and atmosphere in which members of self-organizing teams are willing to help one another and strive to achieve a shared goal. Let us not be overly naive: an important tool in this effort is also level-up rewarding.
CONCLUSION
In a multi-team environment, Velocity is a tool that can help us plan a release. However, it is by no means intended for comparing (or even assessing) team productivity.
Such a practice would lead to many negative patterns, such as:
- At a joint Sprint Planning event, teams primarily commit to simple user stories that will quickly generate a mass of Story Points. Challenging user stories are then no longer understood as a challenge, but as a threat to the Velocity metric and, consequently, to rewards.
- Although they work on the same product, due to rewards tied to team productivity, teams no longer share information and knowledge with one another. This also affects the spread of good AI practices, which can significantly accelerate the development process of team that uses them.
- Teams start estimating user stories with unrealistically high numbers of Story Points, thereby artificially raising the productivity measure (Velocity). This also applies in environments where the organization prescribes the size of the baseline Story Point.
- Teams define a very small baseline Story Point, against which they can then value user stories with a higher number of points.
- Teams have no motivation to improve the Definition of Done, which consequently leads to a decline in product quality.
