Velocity does not plateau over time, why?

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?

• Why does it look bad? Most projects start off with a flurry of easy-to-solve problems and then bog down later as some of the initial assumptions prove wrong and have to be corrected to solve later problems. Commented Jan 29, 2013 at 13:10
• Your team does 1000 points per sprint? Commented Jan 29, 2013 at 15:06
• @BryanOakley Looks more like 100 points/sprint. I take the top line to be the "accumulated value". Commented Jan 29, 2013 at 15:13
• "Points" are intentionally arbitrary - even if it's 1000 points per sprint, that might just mean that one point is maybe ten man-minutes or something like that. Commented Jan 29, 2013 at 18:25
• @KirkBroadhurst Look carefully. The line marked 'Velocity' in the key is solid black and corresponds to the bottom line in the graph. The line marked 'Acc. Value' in the key is gray, like the top line in the graph. You can also tell by inspection that the top line is likely the running total of the bottom data points: the line is flat in weeks when the bottom line is near zero (sprints 6, 9, 15...), has constant slope when the bottom line is flat (sprints 3-6, 10-13), and never decreases. Commented Feb 5, 2013 at 1:35

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.
• For the "hangover" stories, what are you suppose to do? Especially if the sprint gets "complete" for at least a portion of the team and then they have to drag a story in from out of sprint a few days before the sprint ends. From what I've been told, "it averages out". Is this not the correct way of thinking? Commented Feb 5, 2013 at 16:18
• Personally, "it averages out" is fine for me, and my scrum team agrees. Other teams do things like double check finished stories, add extra testing, break stories into smaller pieces, or dogpile on stories in order to avoid hangovers, and that's really more in line with "pure scrum." Commented Feb 5, 2013 at 16:29
• Is it ever a bad thing to have though? For instance, many times we'll do committment purely by the velocity. Commit will include a lot of in-progress stories, and then we'll drag stories into the sprint as needed (and this is planned and expected). Commented Feb 5, 2013 at 16:38
• It's bad if your code is not in a shippable state at the end of the sprint. Scrum purists consider planning to pull stories into the sprint as bad on principle, even if your code is shippable at the end of the sprint. I personally feel it's not bad to adapt the process to fit your team. Commented Feb 5, 2013 at 16:48

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?