How to estimate sprint velocity when there is a change in story points in scrum

Question

Initially, the Product Backlog contained 350 story points of PBIs. After completing 7 sprints of development, the Product Backlog contains 140 story points of PBIs .

The average velocity is 30 per sprint. So it takes 12 sprints to finish the whole project.

After Sprint 9, your client asks to add a new feature. Your team estimates it is 15 story points. Then, after Sprint 10 the client requests another feature to be added. You estimate the size of that feature to be 9 story points. Assuming your team’s velocity does not change, calculate estimates for the total number of sprints.

Scope will continue to increase at the rate of the average of the increases at the ends of Sprints 9 and 10. It will increase at this rate until the Product Backlog is completely burned down during a sprint.

This is where I find difficult. I am not sure how to estimate number of sprints need in this case. What does increase rate is supposed to mean?

Since this is just a estimation, I don't think difficult calculation is needed, does it?

Any help is appreciated.

Answer 1

This seems like some kind of theoretical question, but I can give a few pointers on how to approach this.

You've already identified:

• Velocity (the number of points that can be done in a sprint)
• Backlog size (the total number of points left in the backlog)

The simple formula for "how long until we're done?" is Backlog Size / Velocity. This gives you the number of sprints.

However, you seem to be stuck on "What if new stories keep getting added?".

In this case, you've got a third number:

• Increased scope (The number of new points that are added to the backlog each sprint)

With this extra number, the backlog is shrinking more slowly than it would if there's no scope increase. Essentially, to get the rate of shrinkage, you need to subtract the increased scope from the velocity to get the number of points the Backlog shrinks by:

Backlog Size / (Velocity - Increased scope)

So if you have 140 points on the backlog, you have a velocity of 30 and the increased scope is 12 per sprint, you are essentially burning 30-12 = 18 points of backlog per sprint, so you need a total of 140/18 = 8 sprints to finish up the project.

One of the biggest dangers of Increased Scope is that as it approaches velocity, your total time on the project will skyrocket. For example, if your increased scope rises to 25 points per sprint, then your shrinkage becomes 30-25 = 5 per sprint, and completing the project takes another 28 sprints!

Once it equals or exceeds the velocity, you will never get the project done. This is intuitive to understand; you are generating more work per sprint then you can resolve in that time.

Answer 2

Since the average growth of the backlog is 12 and the velocity is 30 in this example it looks like the projected end point is 15 sprints. The example seems unrealistic since it assumes a constant, predictable rate of growth - probably unlikely in practice.

This is where a burn up chart can be a more helpful tool than a burn down. A burn up chart shows the change in the target scope separately from the trend line.

http://brodzinski.com/2012/10/burn-up-better-burn-down.html