Inconsistent Sprint Velocity

Is the team achieving their Sprint Goal by producing Product Increments that meet the Definition of Done each Sprint?

It's a little tough to fully grasp without the visual but it sounds like the spikes could be due to undone work being moved from Sprint 1 to 2 and then Sprint 2 looks like a lot completed. This trend could continue through Sprint 3 and 4 and so on. 

What does your evidence suggest? 

@Tony.

Team achieving sprint goal when line goes equal or higher to sprint line and not achieving a goal when it is below the velocity line. 

 Here is what i actually want to understand how we can make it consistent or other way why each sprint green line goes up and down.

Thanks for your notes and let me know if I have not made this clear.. 

If someone gave me velocity data that spanned two or three years, I'd discard it. Velocity is a very volatile measure - it's affected by many different factors. It does not have good long-term use. If you're going to use velocity, it's best used to look at a very recent period of the past (2 or 3 Sprints is common) and only use it to make forecasts for an upcoming Sprint (maybe 2).

There are things that interest me a lot more than velocity. Is the team consistently achieving their Sprint Goals? Has the team demonstrated continuous improvement, or at least experiments in the hope of continuously improving? These are things that aren't easily distilled into metrics.

@Thomas Owens

I understand the point where you are coming from. I agree with your point as well that velocity is not something that you can relate for one or two years. 

Or if I ask in this way, say the inconsistency is from beginning to 3 or 4 sprints.  then what do see is wrong and how you can make the sprint consistent. 

Thanks

How might the behavior of the team be impacted if consistent Sprint velocity is a target?

You can have consistent numbers and still not deliver business value or achieve the Sprint Goal. The data you have collected should help the team ask the right questions and make improvements from there... if a result of that could happen to be a more consistent velocity. 

Or if I ask in this way, say the inconsistency is from beginning to 3 or 4 sprints.  then what do see is wrong and how you can make the sprint consistent. 

Velocity is what it is. You don't "make the sprint consistent". You can use the Velocity from the previous couple (or few) Sprints to help guide determining how much work is appropriate to bring into the upcoming Sprint at Sprint Planning. Even then, you also need to consider the team's capacity (for both the previous Sprints as well as the upcoming Sprint, since capacity has an impact on Velocity).

Any use of Velocity over a long period of time, for long term forecasting, or as any kind of target or goal metric is an abuse of the metric.

 @Tony Divel  @Thomas Owens

Maybe I have confused the situation here. Apologies for this.

The question which I have asked in my first post. From that one thing has come up in my mind and forced me to think that if the scrum team is doing the poor sprint planning. 

Then what would you do to overcome this situation? 

Personally I have never got this kind of situation but if this would occur then?

Thanks

Ripan  

I've seen team's that have had a similar trend and it resulted in having a lot of undone work at the end of a Sprint due to either poor refinement or outside dependencies. This may not always be the case though. 

I've seen team's take  a little more time in refinement making sure they're getting not overlooking complexity and dependencies. Some planned less into the Sprint and dialed back their focus to the Sprint Goals and finishing work to their Definition of Done. 

So the problem in the example I was describing is that the team was not able to meet their Sprint Goal and typically had a lot of undone work. This was made transparent by inspecting the Product Increment although the tracking velocity helped support this given capacity had not changed. 

Team achieving sprint goal when line goes equal or higher to sprint line and not achieving a goal when it is below the velocity line. 

Why are the team always unable to achieve a Sprint Goal when velocity dips? What stops them from replanning?

@Ian Mitchell

That is something poor sprint planning if sprint velocity keeps changing.

Scrum team could measure the first few sprints(ideally 3-4 sprints) and decide the average of the sprints and going forward could make it consistent 

Thanks

Velocity is tricky because it's easy to abuse. It's just a sprint planning tool. By comparing a recent trend, you can determine how aggressive/conservative the plan for the next sprint should consider. The goal isn't to maintain consistent velocity, but be able to see the difference when many other variables are the same.

If team took on same points for 3 sprints and had 100% capacity throughout, are the results still varied? If so, it may be time to inspect the quality of the story writing. If the stories are about equal size and not too big, how many unknowns exist sprint by sprint? If there aren't many unknowns, are there systemic/process issues existing that the teams maneuvers around throughout the sprint? How well are the sprint goals being written and realized? Do members of the team have a hard time being productive? What distractions exist?

The intended purpose of velocity is to visualize the trend and consider the variables. From that you can strategize next steps towards consistency and more importantly predictability. What separates a good team from poor team (speaking strictly in terms of results), isn't velocity but predictability instead, to both functional expectations and delivery. Scrum Masters are there to help the team answer all those questions and velocity is one tool that helps indicate a problem needs addressing. 

Or if I ask in this way, say the inconsistency is from beginning to 3 or 4 sprints.  then what do see is wrong and how you can make the sprint consistent. 

Why do you view an inconsistent velocity as something that needs to be fixed?

Why are you focused on metrics that are activity and output-based?   What metrics are you using to assess Outcomes and Impacts?

Personally, outside of using a team's velocity as a guide for them to assess what to forecast in a future sprint, I couldn't care less what their velocity is.   The real question (which has already been asked in this thread) should be around whether the team is meeting their Sprint Goal?   

Some other metrics I would also be interested in:

• How is the team improving?
• What is the quality of their work?
• What is the value they are producing each sprint?

I also agree that there will be cases that your velocity will not be going upwards or going downwards. As what the others have mentioned, there will be a number of factors why it is inconsistent (Unplanned leaves or events, unclear stories). Inconsistent velocity does not equal to your team not improving or not doing considerable work, the outcome or output might not be tangible.

What are you using to calculate velocity?  It is story points that a just guesses based on incomplete information?  Is it number of items completed in a Sprint which could increase or decrease based upon information gained while doing the work?

Have the teams introduced any new technology or new problem spaces during that time that could impact their ability to complete work due to the need to acquire new skills? 

There are so many things that can impact a measurement of velocity.  If I had a team that had a straight line chart of velocity, regardless of what measurement as being used, I would be VERY CONCERNED.  The "consistent pace" dream is an "exact pace". No where that I have ever found a definition of consistent was the word exact used. 

Velocity on it's own is a meaningless metric much like every metric.  Correlate multiple metrics together to be effective. It appears you are using velocity and satisfying Sprint Goal together which is good. But what you are seeing is circumstantial evidence.  Since satisfying the Sprint Goal is actually the more important thing focus on that. Could it be that the Sprint Goal is not being formed effectively? Could it be that not enough refinement is being done? Could it be that the problem's definition has been ineffective? 

I often tell people that charts tell you nothing but you can read a lot from them.  The real key is how you interpret what you read. 

Folks 

This is not something that I am doing. As I mentioned in my first post someone had asked me by showing one paper. I suspect he had got that interview question however he didn't tell me that. 

So I wanted to take some observations that what could be the possible scenario's.

I know velocity could not be the same per sprint based on a number of factors.

But at least after 3-4 sprints team should kinda become predictive that how much team can put into the sprint and finally achieve it. 

That is something the team should consider and keep it improving by assessing the previous sprints in the retro meeting.

Thanks

Stefan Wolpers had an excellent tip/suggestion recently.   

He runs a brief 5-minute exercise with each of his teams where he asks them the question "How would you increase your velocity without actually doing any more work?"   Many teams can brainstorm a number of ways to do this, which highlights the very fact that if velocity is misused as a performance metric, it can be easily gamed.   Velocity consistency is therefore not something that teams should strive for.

This leads me to the question for you Ripandeep - "What is more important/meaningful to the organization, to have a team increase their output (velocity), or to have a team increase their value delivery?"

And no, they are not the same thing.