Calculating the Velocity of Your Agile Projects

A Simple Way to Calculate the Velocity of Your Agile Teams and Projects

Whenever the work is itself light, it becomes necessary, in order to economize time, to increase the velocity. Charles Babbage

 

What is Agile Velocity?

The calculation of Velocity in physics is pretty straightforward, and if memory serves me correctly, it is the first formula I learned. Simply put:

Velocity = Distance / Time

Isaac Newton

In truth, Velocity is a vector and requires a directional component to fully qualify as a Vector. Velocity without a directional component is Speed – a Scalar. What we have in the above formula and what we will actually be measuring is a Scalar – the speed of the team. Velocity as a term has, however, become so widely used in the Agile community that it makes no sense for me to refer to it as Speed. So with apologies to Sir Isaac Newton for the misused term, and for my liberal interpretation (as you shall see) of his first two laws of motion, we shall accelerate into the topic.

If Velocity is Distance divided by Time, what do we use as the numerator or distance unit in our equation? For our purposes, the distance is Units of Effort. My previous post “Agile Planning Poker” explains how to accurately develop estimates for Units of Effort. Time (the denominator) is the length of our Sprint which in my projects is two weeks. Velocity is thus Units of Effort Completed / Sprint. As an example: a team that regularly completes an average of 70 units of Effort in a two week Sprint has a Velocity of 70 Units of Effort per Sprint, or is simply stated as just 70. I prefer to keep the Sprint as the denominator because the team will tend to think in terms of Sprints, but for reporting, or forecasting, I will sometimes use Weeks as the baseline. Whenever I do, I am careful to note the different units.

There is much discussion and debate online about using Story Points vs. Ideal Days vs. Actual Days to calculate Velocity. There are other ways I’ve seen that work with a variety of inputs that are formulaicly balanced. I firmly subscribe to the Occam’s Razor approach to things and thus avoid such complexities. The number and variety of factors that can affect the Velocity of a team are both significant in number, and difficult to quantify (See calibration below). Many of the factors will cancel each other out (electronics systems depend on this principle for noise reduction), but the net effect will be a bias on the team Velocity. To illustrate the difference, think about all of the things that you could quantify to determine their effect on the speed of an automobile. You could measure fuel consumption, manifold pressure, acceleration and a myriad of other things and plug them into equations to calculate your speed. Or you could simply measure how far you’ve travelled and divide by the time it took you to travel that distance. So rather than attempting to measure and accommodate for a myriad of changing and difficult to quantify input values, I prefer to take the simple path and use Observed Velocity. The Observed Velocity is simply how many Units of Effort your team completes in a typical Sprint. For this to be useful, however, you need to calibrate your Velocity.

Calibration

Optimization

Optimization is a process that should be completed before you begin Calibration. There are two things of primary interest to us in our calibration. They are:

1. The Friction or consistent forces that are a constant drag on productivity and reduce Project Velocity.
2. The Variable or Dynamic Forces that decelerate the project or team members and cause the Project Velocity to be irregular.

Optimizing both of these factors prior to Calibration will improve the stability of your Velocity calculation. As the Velocity is the basis for many of the metrics we use in Agile and Scrum, it is important to have a predictable Velocity.

Friction

Newton’s First Law States that “Every object will remain at rest or in uniform motion in a straight line unless compelled to change its state by the action of an external force.” Forces that do not propel your project will slow it down. By minimizing the forces that slow down your project, you reduce the “Friction” that reduces your Project Velocity. Less friction means higher Velocity and greater productivity.

In Software development, there are countless forces that can affect the Velocity of your team. As a team leader, project manager or executive, it is up to you to minimize the external forces that negatively impact on the team’s velocity. Friction forces are more or less constant. You can’t eliminate all of them, but you can reduce many of them. Optimizing them before Calibration is important. Friction forces include:

• Team composition: Are the right people with the right skills on the team.
• Process: Changes to your processes: Agile methods, build, release, testing, etc…
• Environmental factors: Interruptions, noise, poor ventilation, poor lighting, uncomfortable seating and desks, inadequate hardware or software, etc…
• Team dynamics: Some team members may not play nicely with others.

As you can see, most Friction type forces are largely environmental. Their effects are long term. They are also, often the easiest to address. Individually, Friction forces are usually weak forces. Cumulatively, they can have a significant impact. Obtaining optimal Team Velocity requires that they be eliminated or reduced.

Variable or Dynamic Forces

Variable or Dynamic forces are often unpredictable and unexpected. They decelerate your project and cause a loss of Velocity. Their effects are sometimes dramatic, but their influence is often brief.

Newton’s Second Law states:

“The acceleration of an object as produced by a net force is directly proportional to the magnitude of the net force, in the same direction as the net force, and inversely proportional to the mass of the object.”

Isaac Newton

For our purposes, we are viewing this from the perspective of the cost (in terms of productivity) on individuals in the team, or the team as a whole. If you can’t eliminate a force that reduces Velocity (deceleration), then do your best to make it as consistent and predictable as possible  (minimal and infrequent deceleration). The more consistent and predictable the force, the more consistent your Velocity will be. Just like in the real world, accelerating and decelerating objects requires force (energy). Unnecessary acceleration and deceleration not only wastes energy and slows down your team, it also introduces variability. The variations in Velocity make your predictions more difficult. To put it simply: The more you allow your team is influenced by Dynamic Forces and things that change their ability to focus on their work, the more variability there will be in their Velocity  (productivity). This variability makes your forecasts less accurate. Some examples include:

• Team changes: Adding member, losing members, changing roles and responsibilities.
• New tools: Introduction of new development tools, database technologies, languages, etc… require learning, and reduce Velocity until learned.
• Vendor defects: Defects in third party tools and software requiring developer workarounds eat into productivity and Velocity.
• Responsibilities outside of the project: Team members assuming additional responsibilities outside of the project. Shifting between projects can have a dramatic effect on productivity.
• Personal issues: Colicky baby at home, personal health, family dynamics, etc…
• Stakeholders: Stakeholders may not be responsive to requests for information from the developers or tester and thus create delays. They may also have unreasonable expectations of the team.
• Unclear requirements: Lack of clarity or detail in requirements cause unnecessary churn and rework.
• Changing requirements: New project specifications might require skills that are non-existent or weak in the team. Acquiring the skills, either by introducing new team members, or by an existing team member acquiring the skills will impact productivity.
• Relocation: Moving the team to a new physical location upsets the rhythm and impacts their Velocity.

One cautionary note: Velocity is specific to a team and comparisons to other teams are irrelevant. There are many reasons for this, but perhaps the most obvious one is that different teams will develop different Estimates for the same task i.e. Developers on Team A might rate the Effort of a particular story at 6 while Team B might rate it at 15. Further, teams have different skill sets and strengths that make them very effective in some areas, but not in others. Because of this, resist inter-team comparisons – they are simply not fair or accurate.

The Calibration Process

While going through the following Calibration exercise, if your project is affected by Dynamic Forces like those listed above, do not compensate for them in your Velocity calculations. The reason for this is simple: In every Sprint you go through, one or more of these factors will likely raise its ugly head and reduce the Velocity. Some methodologies attempt to compensate for them through calculations. With software developers being the analytical type we tend to be, the temptation to do so can be great, but resist the temptation as in my experience, these calculations introduce additional complexity, with little value. By observing your Velocity averaged over three Sprints as described in the next section, and leaving the effects of Dynamic Forces in your Velocity calculations, you will automatically be developing a Velocity baseline that is biased to implicitly include a Dynamic Force compensation weighting. Indeed, there will be some variability between Sprints, but you should find the weighting to be surprisingly accurate, and most definitely simpler.

Sprint 1

With the changes you’ve made to reduce Friction to moderate the effects of Dynamic Forces, you are ready to start your Calibration. Calibration is fortunately a very simple process, but it takes a bit of time. Calibration is simply observing your Velocity (Units of Effort Completed per Sprint) and adjusting your estimate to match the observed value. There is no formula for this, and there is no right or wrong way to do it. There is also only one objective to the Calibration Process, and that is to use a feedback loop through a Sprint Retrospective to review your Effort Estimates and adjust them so that they are consistent and accurate. The important thing to remember is that you are looking for a consensus from your team so that your team can then use the feedback to create more accurate estimates.

In your Retrospective for your first Sprint, you and your team will examine your Effort estimates for the Sprint and see if you agree as a team that the original Effort estimates were reflective of reality. Remember, that your estimates of Effort are relative. This means that per my previous article, you should find that your results roughly follow as Gaussian distribution. Further, relative sizing between Stories for both Estimate and Actual should be consistent. In other words, if Story A has an Estimated Effort of 5, and Story B has an Estimated Effort of 12, then the Observed Efforts at the end of the Sprint should remain the same relative to each other. If not, change the estimates to align with your newfound insight. Remember, that you and your team are attempting to calibrate or optimize is your ability to assess the Effort of any Story relative to other Stories in your project

The result of this exercise produces a baseline Velocity that represents the Velocity of your team. You may also want to look at Velocity of individual team members, but I find this to be less useful as there are many factors affecting individual velocity i.e. Do you always give the really gnarly problems (the ones no one else can solve) to a specific person, and the really easy ones to someone else. If you do, you may see that the person with the easy problems has a higher velocity than the person with though ones. This is just one of many possible distortions in the measurement of individual Velocity that tend to make individual Velocities less useful.

Once you have completed your Velocity adjustments, and in the same session, I recommend that you jump immediately into doing your Estimates for the next Sprint. Doing so serves two purposes:

1. The team will get better at estimating Effort because the Calibration exercise will be fresh in their minds.
2. The freshly created baseline becomes the context for your Effort estimates for the next Sprint.

Sprint 2

After you complete your second Sprint, repeat the review process described in Sprint 1 and compare your results to others in both Sprint 1 and Sprint 2. Remembering that you are looking for your Effort estimates and observed results for individual Stories to be consistent relative to all other Stories, you should see significantly less divergence between Estimated and Observed results in your second Sprint. As in your first Sprint, adjust your Estimates to adjust with observed results.

Sprint 3

As in Sprint 2, compare the results the just completed Sprint (3) to the previous Sprint (2), as well as that of Sprint 1. Again, make your adjustments. After the third Sprint, you and your team should feel very comfortable about the ability of your team to deliver consistent Estimates and maintain a constant Velocity. If you think there is still room for improvement or you are struggling, go through an additional iteration. The more iterations you do, the more accurate your baseline will be, but keep in mind there is a law of diminishing returns – three Sprints should be all you need.

Your Velocity

With three Sprints behind you, take the average Velocity across all three Sprints. This is your Team Velocity. By reducing Friction and minimizing unnecessary Velocity changes prior to Calibration, you have optimized the individual and team Velocities. Over the course of the project, and assuming there are no significant factors introduced such as losing a team member, you should observe a very stable Velocity for the duration of the project. Some might say that you should continually try to increase the Velocity of the team – that should be your goal. While developers constantly try to improve their skills, and tools improve, it is unlikely that any of the team members will suddenly become significantly smarter or more productive, or the introduction of a new tool will suddenly make a drastic reduction in effort. If you can continue to reduce Friction or external forces, you may be able to increase Velocity, but remember, you should have gone through that exercise before you began your Calibration exercise. Unless your developers are slacking off (in my experience this is rare), you likely won’t be able to squeeze much more performance out of the individual team members. I am not suggesting that you not attempt to increase Velocity, but if you have done your job properly before you began the Calibration process, you should have already realized most of the gains possible. In addition to improving productivity, the purpose of the Optimization exercise was to obtain Velocity value that is more or less constant so you can begin developing accurate forecasts which is the topic for next week’s article.

As always, I look forward to your comments.

Michael