0

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.

3

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.

0

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.

0

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:

  • Poorly defined or understood use cases. (Teams may have better business knowledge and get better clarification. Teams may be getting use cases for with an unclear solution or using new technologies.)
  • Teams may be working on use case with differing levels of uncertainty. (Requirements without a certain solution can require experimentation to find a solution.)
  • Uneven skill levels between or within teams.
  • Teams may be assigned use cases for which the team does not already have the required skills. (This is good for team growth, but increases volatility.)
  • Team location may invite more or less interruptions.
  • Teams cohesion and effectiveness may differ.
  • Teams may have different estimation skills.
  • Teams may fill time working on technical debt and/or learning new skill. (This will reduce measured volatility.)

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.