Calculate Sprint Backlog Changing Rate

Question

I am totally new to Agile methodology and learning it. I have seen lots of tutorials and videos and they've all been very helpful. However, I have one unanswered question from my existing study. The situation is:

In the beginning, there were a total of 100 story points. As part of Sprint 1, 10 were completed. 90 points were still remaining but 10 additional points were added. This makes, again, 100 story points in total.

In sprint 2, 20 story points were completed but none were added, so total points became 80.

In Sprint 3, 15 story points were completed. Total story points come down to 65. The cycle goes on. By the burndown chart, we can estimate some values like:-

Team's average velocity is 15.

In 8 sprints total, 120 story points will be covered.

To complete the work it will take around 7 sprints.

Unanswered question

4. Product Backlog changing rate (My answer is 65 but I am not sure)

If someone can answer this and explain the way to calculate that, it will be very helpful.

Answer 1

It sounds like you might be mixing up the interaction between Product Backlog and Sprint Backlog. The Product Backlog is all of the items the team knows about that might need to be done. My guess is that this is what started at 100 points.

Each Sprint, the team identifies the items from the top of the backlog they think they can get done in that sprint and that becomes the Sprint Backlog. Because your team's average velocity over the last three sprints has been 15, their Sprint Backlog each sprint is probably going to be around 15 points in size.

Once the sprint is planned, we don't want to change the work in the Sprint Backlog. Doing so is disruptive and often unnecessary. Most work can simply be prioritized into the next sprint if it's important. The exception would be emergency work. So, this is why we measure Sprint Backlog volatility. If the team brought 15 points into the Sprint from the Product Backlog, then had to take on three points of emergency work, we could say that they had a 20% volatility in their Sprint Backlog (15 divided by 3). This will happen at times - I've never known a team to avoid it entirely, but emergency work is expensive and almost never represents a good thing for the business or the team (it's usually something like a critical bug or an outage) so we want to keep an eye on how often it happens and how it is impacting our work.

Please note that I used points for the emergency work for convenience. I've also seen teams track hours of this type of work or just a count of occurrences. Also, if you do use points for emergency work, do not count this toward your velocity - it seems logical too, but it results in a bunch of unintended negative side-effects.

Notice that this focuses entirely on your Sprint Backlog. Items can be added or removed from your Product Backlog without concern. There may be some cases where changes to the Product Backlog may be so volatile that they are problematic, but these are more extreme and hard to miss.

Answer 2

A product backlog is a living thing. This is due to one of the core ideas behind agile PM: the product is never finished. It evolves. So there will be an everlasting stream of new user stories - at least in theory.

You are measuring the team's velocity. That's a good idea because it helps the team to pull the right amount of workload. I'd recommend to additionally track the average velocity of the last four sprints. So you have a historical view to see changes and the current status for planning.
And the combination of those two numbers will help you to make an educated guess when the work will be done. But keep in mind that agile PM is change-driven. So it is harder to make schedule estimates than with a plan-driven approach.