Stabilizing Velocity

Have you ever been on a team where your velocity suffered wild variances? Maybe you ended up using a running average instead of yesterday's weather?
Have you heard phrases like, "Well, our velocity last iteration was 3, but our average is still 22"?

Have you ever heard the phrase, "Dude, we need to get this velocity stable."

Have you worked on teams where they took partial credit for done at the end of the iteration? Where maybe you'd split a card strictly on points and award some apportion to the current iteration and assign the remainder of the card to the next iteration.

Velocity should stabilize

It seems much of what we read tells us that velocity will do two things; stabilize and improve. According to the VersionOne Agile 101, we can expect that velocity will stabilize within three to six months. The Agile Sherpa tells us it usually takes 3-4 iterations for velocity to stabilize at a consistent level. James Shore's "The Art of Agile" tells us to give it three or four iterations to stabilize.

But what if velocity doesn't stabilize?

First, take a deep breath; and then repeat after me:

If you have an erratic velocity, it is telling you of a problem. And your problem is not an erratic velocity.
"Velocity is a health indicator. Velocity is a health indicator. Velocity is a health indicator. Velocity is ..."

Velocity lets us know how things are going. It reveals issues to us in sometimes subtle ways.

Think of velocity as heart rate. An abnormal heart rate, be it too fast, too slow, or irregular can indicate a number of underlying issues such as electrolyte imbalance, overstimulation, insufficient rest, autoimmune disorders, thyroid problems, or various forms of heart disease. If you have an abnormal heart rate, it is telling you of a problem. And your problem is not an abnormal heart rate.

An erratic velocity can indicate a number of underlying issues such as poor story composition, dependencies on other teams or individuals, too much work in progress, silos, and various forms of mismanagement. If you have an erratic velocity, it is telling you of a problem. And your problem is not an erratic velocity.

Whatever the underlying problem, it is something you can adjust. Adjustments for which you can observe the outcome. But the important thing to remember is that the velocity is not the problem. Do not try to fix the velocity. Try to figure out what it is telling you and fix that.

What should I adjust?

...poor story composition, dependencies on other teams or individuals, too much work in progress, silos, and various forms of mismanagement.
If an erratic velocity could be telling me any number of things, then how do I know what to adjust? Ask your team. They probably know. They may not know they know, but they can give you indicators.

Let's look through some of the common underlying causes.

Poor story composition

By story composition, I mean story size and dependencies. The larger the story, the more risk there is of getting it to done. But it is not just about making stories small. It is about making them small and independent. Small stories that cannot be delivered independent of one another are really just tasks for a large story.

If we have an issue with proper story composition, we may find we get several stories close to done, but we cannot run acceptance tests on them until all of them are complete, leaving us with too much testing at the end of the iteration. It we don't get all of the stories ready, none of them can move. Then, next iteration, we complete the last strays and a glut of cards/points move to done. Alternatively, some stories are just too big to complete in a single iteration.

Mike Cohn has a number of good resources on creating user stories. There is no need to get your stories perfect up front. Get them good enough to do a high-level estimate; think epics. Then as you start planning releases, break them down into features to get a finer-course estimate. Finally, as you plan iterations, break them down again into small, independently deliverable items. Beware the temptation to split stories across technical seams. Instead, focus on small stories that are thin vertical slices through the technology stack.

Dependencies on other teams or individuals

Perhaps your product owner is not available often enough and there is too much re-work due to slow feedback cycles. Maybe you haven't rights to your various environments and code migrations are executed in durations of days rather than minutes. It's possible some other technical team is not able to be as responsive or relies on process more than interactions for the exchange of information. Whatever it might be, any point where you need to wait for extended periods of time, is likely to lead to other problems. You can't sit idle, so you grab another card to work on, leading to too much work in progress.

Work with these teams and individuals on ways to automate processes or find other ways to reduce their response time. Invite sponsors and others to your stand-ups, iteration planning, and retrospectives. If they consistently don't show, see if you can get another representative. Be professional and courteous, but there is no need to be completely deferent. If the project is important, you should be able to ask for the necessary support.

Too much work in progress

This is a remarkably common issue. In my experience, management often encourages this behavior. I don't know if it is the notion that we will get more done if we work on more things simultaneously. Or perhaps there is a fear we won't get enough things done unless we work on several of them at once.

But what happens when we try to work on a few stories each? Remarkably, we make progress on several, but complete precious few. The more work in flow, the more context switching we all need to make. Coordination of the stories complicates testing and migrations. We look busy, but at the end of the iteration, we've fewer things complete. Then, at the beginning of the next iteration, a glut of work moves to done, setting us up with a couple day delay wrapping up the prior iteration and pushing us into yet another complicated cycle.

Drive each card to completion before picking up the next one. If a card is blocked, make getting it un-blocked a priority rather than letting it wait three days because George on the DBA team has a three-day SLA.


Most teams I work with have three distinct roles; BA, Developer, and QA. Most teams I work with have three distinct phases of their work; gather requirements, build, verify. Even on agile teams, these separations exist. There are clear delineations in the process and clear segregation of responsibilities. But this segregation is a contributor to erratic velocity. How many "agile" teams do you know of where the BA group is an iteration ahead of the developers who are an iteration ahead of QA, leaving us with a three-iteration cycle time and significant lag in our feedback loops between the groups?

Tighten the loops. Get people working together in not only close proximity, but close time-frame. Involve the developers and QA in the formation of requirements. Push QA to the front and automate, automate, automate. Don't let manual testing be a bottle neck. Start development before you've polished the requirements. And don't wait until the end to test it all comprehensively.

Various Forms of Mismanagement

Herein lies my primary onus for the mantra, "Agile ain't practices". Agile is a set of values.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Address the actual problem and use velocity to tell you if you have, in fact, done so.
I see organization after organization pick up practices in the name of agile and apply them devoid of the values. Most popular seems to be daily stand-ups and burn-down charts; two tools that provide project management quick feedback on status so that they can make informed decisions about items such as task assignment or if the team needs to put in extra hours to make the deadline. (By the way, that sentence should make you cringe)

Assigning tasks, driving for excellence in estimating, pushing for points, treating code as if it is only a means to an end, role-based incentives, making the team's decisions for them, leaving the team to make all the decisions (they are self-organizing after all), splitting people's assignment across teams (they only need 1.5 QA), burdensome process, and failure to address impediments are but a few examples of mismanagement.

Don't mess with the math

Don't split cards on points and award some apportion to the current iteration and assign the remainder of the card to the next iteration. I am confident this will normalize your velocity. Much like taking cough medicine subdues your cough. Neither of them cures the real problem. They merely hide the symptoms in hopes the real problem will run its course. Erratic velocity is the result of issues that, left unaddressed, are highly unlikely to run their course.

Address the actual problem and use velocity to tell you if you have, in fact, done so.


  1. Our team started doing Scrum in 2003 and over the years adopted most XP practices and some Lean practices. We do a good job of keeping stories small, focusing on finishing one at a time, limiting WIP. We ourselves pay no attention at all to our velocity - we always try to do our best work and work as hard and well as we can. Evidently it is steady enough that the business feels like it can plan. Years ago, we stopped doing the silly "committing" to N hours of work during sprint planning. We plan enough to keep busy for a few days and bring in more stories as we have time. It works really well for us. We release every 2 weeks, but we could release every day if we wanted.

    Last year there was a period where our velocity spiked very high, and our PO asked about it. Of course they'd be thrilled if we could really get so much done every sprint. We were puzzled by it but had no explanation. Maybe for awhile all the stories were easier than we thought? For sure we had less production support taking our time. We decided to keep an eye on any stories that took much more or less time than estimated. But after apparently our velocity returned to normal.

    I think people get way too hung up on velocity. Don't focus on velocity - focus on how you can improve and do your best work. Then velocity will become steady on its own.

  2. Nice blog Doc!

    This is why I like Kanban, I can measure the flow of value from any point to any other point in the process. Emphasis is on the need to understand the flow of business value, not hit a cadence.

    Velocity is a pulse of the Sprint, not necessarily the work before the Sprint (ideation through progressive elaboration) and it's not a measure of the work after the sprint necessary to get to the real definition of done - which is getting the product into the hands of the customer and getting ROI.

    I was in Pittsburgh a couple of weeks ago doing a CSPO course with Jeff Patton and he said it best - "If we are bad at starting (meaning we don't build the right thing), then we do a great job in the sprint (a.k.a. hit our velocity), and then don't push to get the value into the customers hands... then doing a great job in the Sprint just doesn't matter.

    IMO - Velocity is only Sprint metric and that's the issue. Cycle time changes the mindset, it is just about the Sprint. Doing the right thing at all times is what matters - not just trying to keep numbers steady. Delivering value while focusing on bottlenecks that prevent flow is the goal.

    And of course, kanban also supports your case for limiting WIP, outside dependencies, and much more. I guess I am a bigger proponent of kanban than I thought - thx for the rant ;)

  3. Great insights. I learnt most of these the hard way over the years. If this article had existed when I was a fledgling Scrum Master it would have saved me a lot of pain

  4. Like Lisa, Jon and many others, I too am a fan of Kanban, but your article is good advice for any lean/agile team regardless of whether they use Kanban with or without Scrum, XP, etc.

    Funny that this article isn't really about velocity but the 1st two posts are suggesting there's something better than velocity. Though at the surface they seem to be disagreeing with the article, Lisa's and Jon's posts in a way say the same thing this article does: "the important thing to remember is that the velocity is not the problem. Do not try to fix the velocity. Try to figure out what it is telling you and fix that."

    One thing I like about velocity over cycle time is (warning: off the cuff, half-baked idea coming) that an unstable velocity is more visible than a fluctuating cycle time. Hmmm. How long it takes the average item to get through the system is what it is. You want to reduce that average, or the standard deviation, your control limits, but I suspect most Kanban teams are averaging this over a much larger period than two weeks. I think that's averaging out (hiding) a lot of variability. With a 2-week iteration you get to see more readily that there is a problem. I'd love to see some feedback on this thought.

    Excellent article, Michael.

  5. From the title, I was skeptical of this post, thinking you were going to advise how to stabilize velocity, a terrible practice. I loved the heartbeat metaphor though, it rings very true, and I'm going to use it. Thank you!

    I think it worth noting that healthy heart rates have significant variation over time, and so should team velocities. The key is that it be appropriate for the situation. Abnormally stable velocity can be a symptom of dysfunction just as serious as erratic velocity, and should be examined and diagnosed. Teams with a too steady velocity are often engaging in unhealthy behaviors designed to stabilize velocity, like or at least are not innovating or taking risks, likely not learning how to improve. When teams stay true to their initial point size, where one point is the smallest story they'd ever handle, I expect acceleration over time, with local variations in velocity along the way, in response to the sprint terrain. Teams that have the same velocity every sprint are faking it, as surely as the teams that have 45 degree declining straight line burndowns.