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?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
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:
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.
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:
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:
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: