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?
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:
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.
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!
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:
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.
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?
I see 4 possible causes:
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."