It’s perfectly normal to have a fluctuation at the first ten or so sprints, while the team is finding its rhythm. After that, it’s perfectly normal for velocity to fluctuate around an average. Try plotting a running average of the last five sprints or so and you should see it level out. If not, some of the following may be the culprits:

• The team is trying to adjust their story point estimates based on their recent velocity, instead of keeping the story points constant and adjusting how many stories they take on.
• You are not breaking the stories down small enough.
• Too many of your stories are up in the higher granularities. For example, you have a lot of 20 pointers that you are reluctant to either change to a 13 or 40.
• You have a lot of “hangover” stories that don’t quite get finished in one sprint.

You’re misusing velocity as an indicator of performance, as though some number of story points accepted is a “good” sprint and anything less than that is a “bad” sprint.

Velocity (which is a terribly misnamed concept) should be used as a forward-looking tool for estimating how many features to which the team can commit in the next sprint, i.e. velocity should be used for capacity planning.

http://jimhighsmith.com/velocity-is-killing-agility/

Here’s a salient quote from the article: “The problem is the weight given to velocity and turning it into a productivity measure.”

There may be a problem in what looks to be significant variance in your velocity. This doesn’t mean that the team is doing anything wrong, but the effect is that the team’s capacity for future sprints cannot be predicted very well. Unfortunately, that’s not a question that any of us can answer for you. You need to dig into the subject via retrospective. What’s really happening?

In any event, the most critical measure is missing from your graph. How well did the team do at delivering the value to which they committed? Does velocity fluctuate because they exceed their commitment in some sprints but not others, does it fluctuate because they’re not finishing stories, or does it fluctuate because the commitments also fluctuate?

Additional potential cause: during the later sprints, you are paying off technical debt from earlier sprints.

E.g. you have a management demo after sprint 3 and need to show happy-day scenario. To make it, you do the coding without error handling, without translation support, without unit testing. This is a valid decision, you just need to be aware of the consequences.

So later you add all the nice stuff like excation handling framework, translation support, unit test framework and so on. Your existing coding from the 1st 3 sprints does not have use that yet, so it needs to be updated. This effort slows down the value creation during the later sprints.

For your question, it’s hard to tell why it has fluctuation because it might be because of story card, people in the team, or product owner capability. So, in my experience, the velocity will be fluctuated because, for example:

• Your team member might not be dedicated team members. To work and
  understand each other, they need to work together long enough. If your team
  swap people in the team in/out often, this make dynamic in the team and also affect velocity.
• Story cards are too big. So, team can’t go in detail as much as they can in planning/estimation. They will find during the sprint that something is harder than they think.
• I guess you are doing scrum. In scrum, we have to do sprint planning part 1 (Product owner choose what to do) and sprint planning part 2 (Team decides how much they can do). So, the situation might be, after product owner choose the cards to the sprint, team doesn’t go in detail deep enough in sprint planning part 2 so they can’t find the hidden problem that they need to let Product owner knows. If they found the problems at first, they will break them OR think about how to get rid of the risk. This make the estimation to be correct enough before start working on the sprint.
• If the story cards are not in detail, estimation will not be accurate. The estimation at first can be a rough one but before start the sprint or before the story cards go to the sprint, they need to be splited and clarified enough to get almost correct estimation. This helps velocity of team to be more stable.
• Product owner might not be able to clarify story cards clear enough before start working on sprint. This is also really important thing because this is the goal for the team to work in this 2 weeks. If product owner just choose the card to the sprint and team don’t understand it yet, they anyway need to understand them during sprint and the answer might turn out that it has more than they discussed and the estimation is wrong. So, this clearly affects velocity.
• etc…

Anyway, in my opinion, I don’t think the fluctuation of velocity is important as long as we know what the situation on each sprint. Velocity is just a thing to tell you how stable your team can work. If it’s not stable, we have to find out in detail of each sprint about “what happened”. This is just a way to clarify/make the problem happen so we are able to fix it. So, velocity just tell us what was going on in that sprint to we can think back and improve to make it stable. Velocity is a projection of the project. And the fluctuation of velocity doesn’t mean team can’t deliver product, it just helps you think about the projection in the future and what are the problems to solve to make everything smooth.

Your velocity has noise (fluctuations). Possible reasons:

• Stories are too big and quite often a halfway finished story is lifted to the next sprint.
• The stories were not accurately estimated. This can be because of an inexperienced team or again too big stories.

This noise is not necessarily a problem by itself: a noisy velocity that fluctuates around a constant average still allows you to do accurate release planning.

However, if you filter out the noise (rolling average over 5 consecutive sprints), then your velocity is still going down after 20 sprints. It makes it hard to do release planning and it is worth investigating:

• Is the “definition of done” too weak and the team is piling up left-over work from previous sprints?
• Is the organization getting better at diverting scrum and imposing non-backlog work upon the team?
• The large stories (epics) at the bottom of the back log were estimated more optimistic than the more detailed stories on top?