Scrum Idea: Volatility Factor

Over the past few months, I have been working a lot on release planning for my teams. Not only have I seen the light on its importance, but it has also helped me realize problems with my own prioritization. Each time I change my release roadmap based on additions/modifications to the backlog, I realize how hard planning for the future is.

My solution, the Volatility Factor.

Here is the scenario. You have a team with a velocity of 15. In doing their release planning, you have the next three sprints planned out. After the first sprint planning, the roadmap hasn’t changed. By the time the second sprint planning roles around, the backlog has changed by 5 points. Maybe a large scalability issue was encountered, or your largest customer requested a must have feature or they were leaving. It doesn’t matter what the reason, 33% of your next sprint has changed. This ripples down through the rest of the backlog.

For this team, they have a volatility factor of 33%.

Now, what is the point you might ask? Well, it helps you understand a few things.

  1. How accurate are your roadmaps going to be when you show them to the rest of the company?

  2. How much should you plan for future release?

This last point is very important. In the above example, I should have only planned sprint 2 for 67% capacity and sprint 3 at 33% capacity. This is until the volatility factor starts increasing. It will save time, and give a more accurate results. That way I am not planning for something that is probably not going to happen.

Is volatility a good thing or a bad thing? I don’t really know. I would like to say it is bad, and the lower the volatility the better. But, in an agile world, this volatility may be the difference between building something great, or waiting until someone else has already built it to get started. All I know is it needs to be understood.

Unfortunately, I just thought of doing this today and figured I would blog about it. I haven’t done it yet. I do think it will help expose teams that are hard to plan for and help bring those problems up with the rest of the organization if nothing else, and maybe save me a little time.

Anyone think it is a good metric to track? Or am I wasting my time?