Team velocity fluctuates a lot, how to find the root cause?

Question

I have plotted my team burn up chart and its velocity per iteration. To me it looks really bad (velocity fluctuates a lot). What should I be looking for to diagnose the root cause of this behaviour?

Answer 1

TL; DR

Low but steady velocity is usually fine. Steadily-declining velocity is a strong indicator of an unidentified process problem, which the Scrum team needs to identify and make clearly visible within the project.

Velocity is a Range

First of all, velocity is not meant to be either a management target nor a fixed value. It's an estimation tool, and is really useful for two things:

1. Schedule estimation.
2. Identifying hidden bottlenecks.

By itself, the fact that your velocity fluctuates doesn't matter. You can use a tool like Mike Cohn's Velocity Range Calculator, or a simple trailing average, in order to figure out what your normal velocity range is. Personally, I like to use 90-day trailing average, but the exact methodology is less important than the fact that you should treat velocity as an historical metric for predicting confidence intervals for future estimates.

What Your Velocity Tells You

There's not enough information provided for anyone to tell you why your velocity has so much variance, but it's trending mostly down, and there are a number of sprints that produced zero points. Therefore, one can draw a number of likely conclusions.

• Your project has hidden complexity, or your estimates are wrong.

  If you're consistently missing Sprint Goals (not velocity targets; that's entirely different), you may be underestimating the work-effort for user stories, pulling too much work into each sprint, or are paying the price for technical debt that you took on earlier in the project.

• You had early success, but have hit a wall.

  This may be the result of technical debt, changes to the project, or changes in your team composition. Alternatively, you may have changed your point system, and the easy points earned earlier in the project are no longer artificially boosting your graph lines.

• You're measuring the wrong things.

  Your accrued value continued to rise between sprints 8-14, even though velocity was low. Either your accrued value is completely unrelated to the size or volume of delivered features (possible, but suspiciously unlikely), or you are delivering features that aren't assigned story points within your sprints.

Schedule Targets

Focusing on velocity out of context doesn't ship products. The real underlying question you need to ask is whether you are likely to hit your target dates with your current velocity. If your earned value is sufficiently high, your Product Owner might be able to declare your project a success at any given point and call it "good enough."

If your shipping targets are slipping, then your velocity is just a signal that you have a process problem that is not being captured in Sprint Planning or Sprint Retrospectives. This is a process failure.

What You Can Do

Regardless of the nature of the process failure, the solution is to leverage team communications to bring those process problems to the surface. Once the faulty processes have been identified, the team can make informed decisions about how (or whether) to resolve them.

As always, the goals are transparency and visibility. Make the project's process and progress fully transparent, make the problems visible, and then put Scrum's inspect-and-adapt cycle to work!

Answer 2

As pointed out by CodeGnome, velocity is always going to be a range. However, if you find that your velocity fluctuates a lot, here are some things to check and suggestions for improvement:

1. Do you account for holidays? For example, if you run 2-week sprints, you may have one sprint with 2 holidays which is 20% less duration than a normal 10-workday sprint. Also, if some people are on vacation, you will have less capacity. May be you want to adjust your sprints for 10 working days, instead?

2. Improve your estimation: Perhaps your point estimation is not consistent. Some people use benchmark stories. For example, identify a typical story as a 1-point story and another as a 2-point story and so on. When doing the estimate, use those to compare. Is this story more effort/complex than the benchmark story?

3. Unbalanced work: You may have work that is not balanced across development, design and testing teams. This may lead to idle time in some disciplines. The solution here is to get the team to be more cross-functional.
4. Impediments: Do stories/tasks get blocked often because of impediments? If that is the case, track impediments, assign accountability and adjust your sprint, as needed.
5. Rework: Do you have lots of rework? May be the team declares a story completed and the Product Owner asks for fixes, involving rework and retesting. The solution here is to write testable acceptance criteria upfront.

Answer 3

Draw a line that represents the rolling average over that period, then draw lines that represent upper and lower control limits at 1, 2, and 3 sigma. Then analyze again. Your Y axis goes from zero to 1,000 which can make normal variation look extreme and volatile.

You must use control limits to determine if you have a special cause. Else, you have normal, random fluctuations.

Once you have the new graph, repost.

Answer 4

CodeGenome, Ashok and David have all given excellent answers.

What I would suggest before proceeding with a root cause analysis is to challenge your basic assumption that there is a problem. You say that to you the variability in sprint velocity looks bad, but does this variability have business impacts that warrant the time and effort to investigate the root cause, develop and implement corrective actions, and then monitor the effects of that corrective action on future projects?

Answer 5

I see 4 possible causes:

• Maybe the "value" of your story points fluctuates wildly for "political" reasons, such as inflation/readjustment, etc. See e.g. this:

http://www.industriallogic.com/blog/stop-using-story-points/

That is, your team may be subject to political inflation or manipulation of story points. Unfortunately, in organization whatever measure we use, it tends to degenerate as people try to go for maximizing the measure instead of producing tangible results. Perhaps this is what E. Deming had in mind when he formulated this:

"Eliminate numerical goals, numerical quotas and management by objectives. Substitute leadership."

• Your team is trashing in finding good grasp on what a story point should be worth.

• Work varied significantly causing productivity drains in some periods due to having to learn and/or solve problems associated with working in new territory.

• Your team optimizes for "earned value" and treats story points estimations carelessly.