Should the Actual Velocity measurement include “Unplanned stuff”?

A question that keeps popping up here is whether or not the Actual Velocity (i.e. the sum of the Story Point values of all Done-Done stories from a sprint) should include “Unplanned stuff”. I.e. things that were not expected and which are not really part of the Sprint Backlog. The question assumes that the team somehow estimate (in Story Points) that “unplanned stuff” as it appears, and put it into the Sprint Backlog, and consequently track it to Done-Done state and as a consequence include it in the Actual Velocity measurement.

First of all, I think the way to go is to minimize the amount of unplanned stuff. Period. If you have lots of unplanned stuff then you should consider shortening the sprint length, or possibly look at how well the Product Backlog is managed and prioritized.

But there may still be unplanned stuff that appears. There’s no way around it. It’s a reality and we have to be agile enough to be able to handle it.

Let me just emphasize that if you were to estimate the unplanned stuff, you would have to estimate it using the same unit and estimation reference as the regular User Stories; otherwise the Story Point values would not be comparable or possible to sum up. In our case we estimate all our User Stories using “Gnome days” (se blog posts below), so the Story Point value of the unplanned stuff would have to be estimated using that unit too.

So in every sprint we have two alternatives, right: either you do include unplanned stuff (in Actual Velocity) or you don’t. Let’s take an example where we have a team doing a sprint starting out with 30 SP of Estimated Velocity. Let’s also assume that the team so far has had no unplanned stuff appearing in previous sprints and the Estimated Velocity of 30 is pretty accurate and stable.

Case 1: the team decides to include “unplanned stuff” in the Actual Velocity measurement
The team works for a sprint and there’s a bunch of “unplanned stuff” that appears. The team estimates it and includes it in the Actual Velocity measurement at the end of the sprint. The team’s Actual Velocity will probably be close to the Estimated Velocity, even though parts of the work Done-Done is actually “unplanned stuff” that has replaced User Stories that were originally part of the sprint backlog. As a consequence the team will have completed less User Stories than expected, because it had to deal with that unplanned stuff. So the understanding of the team’s velocity at the beginning of the sprint has proven incorrect, in the sense that it incorrectly indicates that the team can perform 30 SP of User Stories from the Product Backlog. That is true only if there’s no new “unplanned stuff”.

Case 2: The team does not include “unplanned stuff”
The team works for a sprint and the unplanned stuff that appears during the sprint is not included in the velocity measurement, so when the sprint ends the team’s Actual Velocity (25 SP for example) will be lower than the Estimated Velocity (30 SP in the example above) – because the team was distracted from the original sprint backlog doing that unplanned stuff. As a consequence, on the next sprint planning the team will observe its past Actual Velocity (25 Story Points in this example) and they will thereby commit to less. This way, they automatically adjust for a “similar amount” of unplanned stuff to appear in future sprints.

Conclusions
Given that you have a relatively steady inflow of unplanned stuff (as opposed to very rare occurrences, or spikes) in your sprints then you do not want to include Unplanned Stuff in your Actual Velocity, because it decreases the quality/reliability of the measurements. As a consequence you risk constantly taking in more User Stories than you’re actually able to complete.

Note that I’m not saying that you shouldn’t estimate or do the “unplanned stuff”. If there’s unplanned stuff that appears that has to be done, then sure you can include it in your scrum board, estimate the remaining time and track it in the burndown. But do not give it a Story Point value and do not include it in the measurement of Actual Velocity.