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.
Silos
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.