How handle the change in baseline story

Question

We follow Agile Scrum. We had identified a baseline story for story point estimation and used it for many sprints. We had a velocity calculated. After sometime, the team found that the baseline is not correct and a simpler story should be the new baseline.

Now, do we lose the velocity accumulated up until then? Or, is there a way to adjust the velocity?

Answer 1

Don't adjust anything.

It doesn't really matter. Your calibration/baseline story is likely to only be 1-3 pts (at most), so recalibration will make little difference (and never revisit old points, just learn).

Why do we estimate in scrum?

We estimate

• To ensure the team don't take too much on in a sprint (but we can do that via story counts just as well)
• To ensure the PO has just enough work ready for the next sprint at planning (but story counts again)
• To allow the PO to do longer term planning (but this is better done via real metrics like cycle time and wip)
• To ensure the team don't take a too large story into a sprint (but a mature team should be able to gauge without looking at points)

Any other use of velocity is trying to get back to PMO project management, so is in conflict with Scrum.

Any velocity should be an average, so it'll work out on its own in the longer run.

Velocity measures the value in doing the story in precisely no way, so don't sweat it.

Remember Ron Jeffries who invented story points now advocates against them.

Answer 2

Scrum is silent on how to determine how much work to bring into a Sprint. Basing it on past velocity is one way, but there are others. If your team feels comfortable using velocity, consider only looking at the past few Sprints. In Extreme Programming, the term is Yesterday's Weather. Look at the average velocity of the past 3 or so Sprints and use that to plan your next Sprint.

Now, you've changed your point values. You can bring it what feels right, and in 3-5 Sprints, your velocity will have recalibrated itself. Be sure to focus on the most important work first, and perhaps have some extra backlog items refined and ready should you underplan what is brought in and be ready to engage the Product Owner on the right course of action.

There's no need to overthink this. Your team may have a good feeling for what they can accomplish in a Sprint. In a few weeks, your velocity can once again be used to plan a Sprint.

Answer 3

Estimation and simple math.

Let vOld = old velocity

Let bOld = effort of old baseline

Let bNew = effort of new baseline

Let vNew = new velocity

Therefore:

vNew = vOld * bOld / bNew

Note that if measuring in new points, bNew = 1. Therefore:

vNew = vOld * bOld

For example. Let's say your old velocity is 50 points/sprint. Let's also say your Team estimates your old baseline story to be worth 2.5 story points using your new definition of points. Thus, your new velocity is 50 * 2.5 = 125 points/Sprint.

The trick will be accurately and precisely estimating bOld in new points. Note, however, that assuming that the conditions are similar (same developer worked on both stories, no obvious modifiers to performance like interruptions, sleep deprivation, no large gain from improved knowledge etc.), then this estimation will be relatively easy, as all you need to do is look at the difference between the actual time both stories took. For example, if bOld took 5 mandays and bNew took 3, then bOld is 0.6). You should therefore try to pick stories that had as similar conditions as possible.