Mike Lyons defines agile velocity as the number of story points a team completes each sprint, usually averaged over three sprints. It predicts future delivery but fails for performance reviews or comparing teams, since story points are relative. Only finished work counts, and pushing teams to raise velocity continuously backfires.
One of the best things about agile delivery is that it's based on empirical data. And one of those pieces of data is velocity. Velocity is a metric that refers to the actual amount of work completed, sprint over sprint, typically a rolling average over the last three sprints. It's actual data, the number of story points delivered to release a thing of value every sprint. And this velocity should stabilize over time. In other words, when teams are first starting out, they might have high velocity one sprint, lower velocity the next. And it may sort of fluctuate, but it should stabilize and become predictable going forward. Velocity is used to predict delivery in future sprints. Velocity can be affected by holidays or time out of office, whether it's planned or unplanned. Maybe someone's on vacation or maybe someone else got sick. That will affect the number of story points we can deliver, changing our velocity. It's not a performance metric. It shouldn't be used to compare one team to another. We know story points are relative, so you can't compare one team to another. A team that has 100 points of velocity, another team has 35 points of velocity. You don't know which team is better or if they're better. We don't. We can't use velocity for that. And velocity represents the amount of work completed. We don't actually get to collect the points of work we didn't start. That should make sense. But you don't actually get points for work in progress or partial credit. We don't do that on teams. Work is either done or it's not. If it's done, you can have the points and it can count for velocity. If you started it but didn't finish, no point. And then finally, velocity should stabilize over time. We don't want wild sways in velocity numbers as we move forward because then we can't be predictable. Sometimes capacity can be confused with velocity. So let me provide some clarity there. Velocity is an empirical piece of data based on the actual points we've delivered. Capacity is a guess to what we think we can deliver in the next sprint. We base it on velocity. Sure. If we have a 40 point velocity over the last three sprints, on average 40 points, our capacity should be 40 going forward. We think that's what we can accomplish. If there's no holidays, people are all going to be here. The full team will be working on our program. Then our capacity is probably the same as our last velocity. But it's something we're predicting we're going to do. It's a best guess. And we'll load up story points until we hit that capacity. Now, at the end of the sprint, when we deliver now, that becomes velocity. So maybe our capacity was 40, but we delivered only 30 points. Well, that impacts our true velocity, because velocity is based on what we did. I was working with a client one time and they wanted us to commit to increasing velocity, sprint over sprint. And I asked them, first of all, we won't commit to that, but second of all, I don't think that's what you want. You want predictable and stable velocity so that we can use that as a prediction, as a planning mechanism, but you don't want me to increase it over time. I think what you're asking is you want us to get better and get faster, and we certainly will. It just won't be reflected in velocity. Think about it this way. When a new story shows up on a team, they've never seen it before. It's some sort of new area. There's a lot of complexity, unknown. It's going to get a high number, it's going to get a 20 or it's going to get a 13. It's going to get high numbers of story point estimates. But then later on, as the team gets better, they've done that type of work and they see a similar story come in, the estimates going to be lower. It's going to be maybe it's an eight, maybe it gets even lower than that and becomes a 5 or a 3. It's the same type of work. It was a 20 and now it's a 3. It's the same work. Our velocity isn't actually going to change. If anything, our velocity would decrease if that was the only thing we did. But instead what you're going to get is actually more work. So the amount of work we can deliver will change and get better and faster. We'll get better at what we're doing, but it won't be reflected in increased velocity. So don't allow people to use velocity as a performance metric.
