# Velocity / Capacity charts

Velocity is a common indicator, that's clear.

What puzzles me is that Velocity on itself is nothing as velocity changes directly with the capacity of the team and people take days off, gets sick, teams grow and shrink ... to get a useful indicator you should be measuring Velocity vs Capacity to get something like:

You get 10 story points from 1 capacity

This way you can:

1. Calculate the delivery of the next sprint. You have X capacity you will likely deliver Y.
2. Monitor the value over time as its fluctuation means things that are happening on the team.

Is this a common indicator and if it is not and people just monitor Velocity why it is not an issue?

You have here a valid point: the velocity is dependent of the team context. More precisely, velocity is calculated on the base of completed stories, and the story points are estimated by the team based on its ability to deliver comparable stories and is hence influenced by shared experience.

If you add capacity to the team, you may in the best case immediately increase velocity. But since it’s about teamwork, and at least some things have to be done together, the increase will never be proportional. Hey! this is software, not factory work :-)

What will happen whenever you add or remove people in a team, is team dynamics : the team will adapt to its new configuration pass through some kind of forming, storming, norming and performing and dynamically adapts. Maybe the velocity will even initially decrease because of friction or time to learn of the new team colleague. Maybe the team will learn from its new performance and estimate slightly differently.

There will be an evolution of the velocity over a couple of iterations and it will stabilise around a new velocity, the new normal of the team.

Edit: even if you keep the same team and some members are away, you cannot easily deduce the capacity. Of course, if most of the team gets a coupe of days off, you could approximate the expected velocity proportionally. But if a few people are ill, the velocity will heavily depend on the team structure and the remaining skills (e.g. if you have only one developper specialized for UI front-end development, and this person is ill, your velocity will decrease over-proportionally because of the bottleneck, unless you have a lot of backlog items that do not require these specific skills.

• Agree with what you mention, but as in the previous comment, you will see in a velocity chart an improvement on the velocity and you will not have an idea if it is because the team is improving or if it is because the team is bigger or if it is because there are fewer blockers ... the point is that Velocity as an indicator alone only tells you how much was delivered which has no value on its own if it is not correlated with other factors IMHO. Commented Jan 19, 2021 at 10:49
• @IgnacioSolerGarcia Thank you for the feedback. In fact this is what I tried to say when I wrote “velocity is dependent on the team context”. Whenever the team composition changes, the meaning of velocity changes as well, and comparing velocity before and after is like comparing apples and oranges. The bigger the team change, the less meaningful it is to compare velocity before and afterward, and the more risky it is to use past velocity as prediction for future performance. Maybe I should emphasise it more. Commented Jan 19, 2021 at 11:35

Velocity is a measure of how much stuff a team gets done in a unit of time. It's comparable to the velocity of a vehicle, which tells you how much distance the vehicle covers per unit of time. The velocity of a vehicle doesn't tell you how much the vehicle is carrying or can carry, the velocity of the team doesn't tell you what the maximum amount of work that the team can do is or if the load is changing over time.

Velocity changes with more than just the capacity of the team. Processes and tools also change velocity. One of the principles of Agile Software Development is regularly reflecting on the team's effectiveness and adjustments to maximize effectiveness. These adjustments can impact velocity. Through these changes, it's possible that a team increases its maximum capacity over time. If that happens, it's also possible that the team can maintain a steady velocity even if capacity is reduced.

Distilling capacity to what is effectively the number of hours worked doesn't fully address the capability of the team to get work done. Beyond the process changes that an agile team should be making on a regular basis, you need to consider team dynamics, tooling and infrastructure, and the skills needed to do the work in front of the team. Changes to any of these could impact the ability of the team to carry out their work.

These problems, though, aren't common for teams that understand what velocity tells them. Velocity, regardless of how it's measured, does give you a nice numerical value that can be plotted over time. That is just the beginning of the story. Another layer would be Yesterday's Weather, or looking at the average velocity over a rolling average of iterations. Yesterday's Weather can smooth out some of the one-off changes around vacations or sick leave. However, the next layer isn't quantitative, but qualitatively understanding why velocity has changed - looking at changes to the team composition, changing the process, changes to the context, or something else. Teams that effectively use velocity do use these qualitative properties.

• Agree that velocity changes with more than just the capacity of the team and that's exactly what we should monitor because that's what really means that there are internal changes in the team and these always need to be understood. Essentially what I was thinking is to remove the noise that comes from capacity changes to be able to properly evaluate the changes that come from improvements done by the team looking at some charts. Commented Jan 19, 2021 at 14:36
• @IgnacioSolerGarcia I'm not sure what you mean. If you're using velocity, you probably should be charting that velocity over time. You should also be charting a rolling average velocity, probably on that same chart. You can use bars for iteration velocity and a line for rolling average velocity. Then, when you notice a change, annotate the chart with qualitative properties. You can use regular retrospectives to review the chart and determine what those qualitative properties that likely led to changes in velocity were. Commented Jan 19, 2021 at 15:36
• What I meant is that if I do what you say in the comment without charting the capacity too I will get a lot of noise as there is always something: a day off for someone, a bank holiday, someone sick and whatnot. Charting velocity/capacity removes that noise and points to changes that need to be qualitative. Commented Jan 20, 2021 at 16:19
• @IgnacioSolerGarcia That could work. I prefer to annotate based on the rolling average, not each Sprint's velocity. It generally has the same effect, especially if you understand that there will be minor variances and you only need to annotate significant changes. You can use some basic statistical analysis techniques to figure out what significant means based on your data. Commented Jan 20, 2021 at 17:04

So Velocity (as defined by scrum) is the total number of completed points within a sprint.

So lets unpack that. The points are assigned story by story through estimating the effort required, eg: total amount of time. So the points themselves are `time` units in a forward looking direction.

The sprint itself is a block of time. The total number of days working days it covers. So again `time` units.

So it has dimensionality of `time/time` - Its just a unitless ratio. Of course its displayed as just a big Numerator all alone, but it is per sprint and that is the Denominator.

So the one thing we can say is: this isn't velocity.

Velocity is a vector in the units of `distance/time`. Its not even speed which is just a unit valued `distance/time`.

This unitless ratio that you are using has very little value. It can:

• Impress people that we are moving at speed, because you know velocity and see how big the number is. It looks even bigger when the denominator is hidden.
• Reveals how pessimistic your team is about the amount of work they can do. Remember higher values mean they believe they can get less done than their track record.

At best this is a point in time value for roughly converting the estimation of time of a group of work items into the time to budget for that group.

It is rough because it is a point gradient. It does not say anything about the time `prediction of time/time taken` for any other point on the every changing surface of complexity, uncertainty, capability, and co-ordination.

It roughly works because of the law of averages, and law of big numbers. You are essentially performing a Fermi Estimation. The problem is that Fermi estimation improve in quality the more terms are in them, and they are usually accurate to an order of magnitude. Your limited by the number of work items you have, the more of them the better. But even if you can really push those items into the high figures you will still have an accuracy that happily accepts the difference between 1 sprint and 99 sprints, as being off by an order of magnitude and good for gold. Oh and a lot of time spent estimating, not working.

If this value manages to stay similar across a number of sprints, and those sprints are broadly similar then you have found a locally consistent surface. If you are in the same neighbourhood and the assumption that its locally consistent holds, then you can use this number very accurately.

Take a look a Joel on Software: Evidence Based Scheduling for some better ideas on estimating delivery.

• I somehow agree with your comment but then it does not explain why is so widely used and known by everybody, Maybe is an antipattern like the singleton was back in time. Commented Jan 20, 2021 at 16:23
• Ah, Thought I did. Let me highlight, in the middle: LOOK ITS A BIG NUMBER. I CAN"T DO MATH. I AM AN IMPORTANT MIDDLE MANAGER! PAY ME! But aside from that it was part of Scrum TM and as such when scrum became popular (sorry enforced by business owners who cannot program) so did it. Also some engineering teams do happen to operate on a locally consistent surface (law of big numbers), even more so when Scrum becomes bureaucratic. Thus the number can be used to magically and better than random predict next weeks work. But that assumes a lot, and isn't always better than random. Commented Jan 20, 2021 at 23:01
• Being a developer and working in a complex environment does not mean you cannot predict what is going to happen or how much a feature costs. That's being done consistently by so many teams. Commented Feb 14, 2021 at 17:37
• @IgnacioSolerGarcia I do agree that it can be predicted. "Velocity" just fails at being a mediocre mechanism for making such predictions in anything other than fluke situations. I did point you to a superior solution for estimation in Joel's blog. One that actually provides a good view on the inherent uncertainty in estimation and can actually be used for understanding changes in capacity. Commented Feb 14, 2021 at 23:33

The problem with trying to do this kind of thing with velocity is that you never have enough information to make a statistically valid statement at a greater level of detail.

For example in your case, say bob is off that sprint and the capacity is reduced. But its reduced by bobs normal output, not by his capacity.

what is bobs normal output? well what with the variation in task estimates, changes in team structure, different types of task etc etc I doubt you have enough data to say anything with any confidence.

Sure if you have a short sprint or a national holiday or something you could maybe adjust the velocity for averaging purposes. But you are on shaky ground. Are people more effiecent with ahorter sprints? Does less work get done on mondays anyway? etc

• I agree that the issues you mention do exist but this does not address the problem that velocity on its own is not a valid indicator if it is not linked somehow to capacity. Commented Jan 19, 2021 at 10:46
• its as valid as you are going to get, you make it less valid by adding in additional things without a proper statistical analysis
– Ewan
Commented Jan 19, 2021 at 10:54