Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
There is varying volatility across Scrum teams. I understand that volatility can be caused by many variable factors. The table below shows how much it's varying across teams:
Velocity Volatility
Team 1 47 11%
Team 2 68 6%
Team 3 24 2%
Team 4 71 14%
Team 5 34 3%
Team 6 21 27%
Team 7 28 7%
Team 8 32 22%
How much volatility should be acceptable? I understand that it can't be zero.
I've only just read up on "volatility" but to my understanding I don't see much wrong with it. It is a measure how fluid your project is. This is what scrum was designed to handle.
I'd say the underlying reasons for that volatility are far more important than its scope. As such I wouldn't put a hard limit on it but something like a "warning limit" where you start to investigate why this is happening. Maybe use the retrospective to determine if it has a detrimental effect on the team and use those answers to guide you to a adequate threshold.
From a Lean point of view, I'd say the important thing is not how much it is, but that the team is able to fulfill its mission, and perhaps that the volatility doesn't increase. Rather than choosing a metric like volatility to track, I would focus on understanding the current flow of the team (e.g. using a Kanban board) and fixing any problems. As you understand and improve flow, other things often straighten themselves out.
Don't get too focused on volatility. I am just a concerned by the teams with the lowest volatility (that may be gaming the system) as those with high volatility (that may be overcommitting/underestimating.) You may want to understand how the teams at each end are getting to their rating.
There are likely multiple factors applying to any one team's volatility. Volatility can come from a number of causes such as:
On average people in IT tend not to have the best interpersonal skills. I certainly have far less skill than my wife. Forming an effective team involves interacting on many levels. How well a team functions is likely to impact its volatility.
Try looking at your data: - Sorted by velocity - Sorted by volatility - Calculate velocity/volatility - Calculate volatility/velocity
It appears you may have two teams that are having difficulties. This could be for any number of reasons, some of which may be outside the team.
You may have four teams that are gaming your measure. They may be making good use of time made available when they overestimate a sprint.
You don't have trend data which may also provide good information. Generally you would expect velocity to increase and volatility to decrease (to a point). Changing assignments can break trends.
How much volatility should be acceptable?
I'd answer it with another question... why are you concerned about volatility at all? Any tentative of answering the former without thinking on the latter could be considered management BS.
Knowing how volatility is important (or not) in your context, then you can define what's your volatility limit.
Is like saying 'how many defects a story is supposed to have? It's a nice question, so long you want to use this information to improve. Maybe having zero defects, the team is wasting a huge effort on silly defects... maybe having 10 defects out of each story is way too much - but again, it'll depend on your context.
