Agile is no longer just a buzzword; almost every technology company in North America (and beyond) is trying to leverage, adopt or experiment with an Agile variant. I will not pretend to be an authority on the ‘right way’ or the ‘wrong way’ of transforming delivery to Agile but will passionately argue my case against using Agile Team Velocity (or Sprint Velocity) as a measure of productivity and performance. For many in the Agile community, this is a no-brainer and they can certainly do away with this article. However, I come across this topic in real-world situations far too many times than I care to admit; in most of these cases, velocity is used as some sort of a precise scientific formula to determine a team’s performance and productivity. On rare occasions, I have also come across situations where velocity is used to deduce the productivity of each team member. I respectfully (but vehemently) oppose such use of velocity as I believe that it goes very much against the Agile fundamentals.

Understanding and Decomposing Velocity

Velocity is a measure of pace at which a stable team can consistently turn Product Backlog items into releasable business functionality over a fixed time period (i.e., iteration / sprint).

Let’s evaluate two key concepts mentioned above:

Measure of Pace

Product Backlog items are typically quantified using story points, which are nothing more than a relative size estimate, completed by the Agile team using the same reference point (i.e., an item collectively well-understood and estimated to be a certain size). Let me elaborate further with the illustration below.

Relative sizing is unique to the team that does the estimation; no two teams would have the same perception of whether a given item is ‘medium’, ‘big’ or ‘very big’. It is all relative to the collective team’s perspective and could require 40 hours of effort or 4 hours of effort in practice. Frankly, it really doesn’t matter; the goal here is to size the product backlog items and move over a digestible chunk of work to convert to business functionality in a fixed development cycle (i.e., iteration/sprint).

The team will need to use ‘trial and error’ in the first few iterations/sprints to determine just the right amount of work to migrate from Product Backlog (i.e., not too much and not too little). Over time, it will reach a point of predictability where the team could confidently commit to completing a certain number of story points in each iteration. Guess what? You never needed to estimate the ‘number of effort hours’ for each product backlog item throughout this process – this is because we took a bunch of stuff (with relative sizes) and put it inside a finite timebox (let’s say, 4 weeks). We played around with adjusting the number of items inside this finite timebox to determine how much can fit in there until we achieved just the right amount.

Now you know exactly how many of the product backlog items you can convert to releasable business functionality in each iteration. If you know how much is remaining in the Product Backlog, you can also determine the amount of time it will take to complete everything in the Product Backlog and conclude delivery.

Stable Team

A group of individuals who work together as a team regularly and have been doing so for long enough to have established alignment, working norms, collective understanding, and a team intuition. This team is critical to establishing a stable Agile velocity, and to be able to predictably determine the pace of progress on converting product backlog items to releasable business functionality.

Keep in mind that swapping out team members, reducing “allocations” or making changes to team dynamics would impact the velocity (i.e., predictability and pace). As a result, the velocity will re-stabilize to a new normal once the new (or updated) team reaches a mature state.

Why is Velocity not indicative of Performance or Productivity?

Velocity is merely a measure of pace, grounded in relative sizing of work by a given team; one team’s velocity of 100 is no better than another team’s velocity of 10, if the two teams estimate the same piece of work (e.g., sketching a circle) to be 100 story points and 10 story points respectively – remember, it is ALL RELATIVE.

Velocity encompasses and consolidates many factors including overall team maturity, individual experiences, and team members’ availability over an iteration. It is certainly true that a mature team with a stable velocity over multiple iterations may leverage velocity data points to diagnose delivery problems that may be caused by an array of issues (invalid assumptions, unavailable team members, and other bottlenecks).

How to determine Performance on Agile Initiatives?

I am aware that I run the risk of oversimplifying the answer to this question, as I form the sentence ‘based on delivery of actual business value’. At the beginning of this article, we referred to the conversion of product backlog items to releasable business functionality – this business functionality is the key to demonstrating performance and productivity. Agile is rooted in a close partnership and collaboration between business (customer) and technology; the product backlog prioritization and estimation help business (customer) assign ‘value’ to functionality that is released (or could be released) at the end of each iteration – use this tangible business value to demonstrate concrete progress and delivery performance. Depending on questions and interest, I will be happy to elaborate on this topic further at another time.

Common Mis(uses) of Team Velocity & Implications

Since team velocity is often misperceived as a measure of performance, there is typically an attempt to extrapolate additional information from this metric in pursuit of a more calculated answer to the question of ‘delivery progress’. Let me illustrate with an example, and a few decision variants I have observed over the years:

The team velocity on Project Ape (with 5 team members) over the past 6 iterations of 2 weeks each was stable at about 20 story points – this leads to the extrapolation that each team member must be completing 20/5 = 4 story points/iteration

Decision Variant 1

Since we want to get this project completed faster (or accelerated), let’s add 3 team members to the project and increase the velocity by 3 team members x 4 story points/team member = 12 story points, leading to a total velocity of 32 story points per iteration.

Implications

• Velocity is a team metric and not an individual one – each team member contributes towards the end to end delivery of each work item and any attempt to distill individual effort from the collective would be counter to the very tenet of teamwork
• Story points are ALL RELATIVE and are only meaningful to the team members who estimated them based on their unique (but collective) assumptions
• It is unreasonable to expect a new set of team members (with varying experiences and no contextual knowledge of the initiative) to join a mature team and immediately ‘accelerate’ velocity – you are more likely to expect a drop in velocity due to learning curve and the fact that existing team members would need to train the new folks; once fully onboarded, the team will find its way to a stable velocity

Decision Variant 2:

Since we are experiencing budget cuts, we can replace ‘more expensive’ team members with a higher number of ‘less expensive’ team members, and at minimum, sustain the same velocity.

Implications

In addition to what’s stated for Decision Variant 1, keep in mind that a mature team is typically performing at an optimal level after working its way through the team forming stages (forming, storming, forming, and performing) – it takes a long time to get there. Also, there isn’t a linear relationship between more team members (resources) and more progress; in fact, this can have an opposite effect if the individuals are unable to work as one cohesive team.

Decision Variant 3

Since the team feels that 4-week iterations are more suited to this work, they can move to 4-week timeboxed iterations immediately with 200% of prior stable velocity over 2-week iterations

Implications

It is good to empower Agile teams to make informed decisions based on their learnings. If the move from a 2-week iteration to a 4-week iteration is deemed beneficial, it is certainly the right move. However, mandating the velocity target in the new timeboxed iteration would be counterproductive. Agile provides an adaptive mechanism that helps refine planning parameters (such as velocity) based on actual delivery. Therefore, instead of mandating velocity targets, allow the team to collectively decide on a target and let them prove/disprove its validity through actual delivery. This requires putting trust in the team that they will do the right thing, and not slack off knowing that they now have 4 weeks per iteration.

Final Thoughts …

I did not set out to write a long article on Agile team velocity, but I recognize that this is a rather complicated and polarizing topic that links back into other critical areas including basic Agile mindset and values, team building, leadership, and trust, among others. However, I hope that this article helps you reflect on your own Agile journey and more specifically, the use of team velocity in your organization. I urge Agile, practitioners, coaches, and leaders to continue to evaluate the application of basic Agile values and principles in your organizations prior to scaling across programs, portfolios, and enterprises for a sustainable and productive outcome.