Sprint Velocity - Dealing with incomplete stories

May 21st 2016 (updated Apr 3rd 2023)

agilescrum

Velocity

I recently had someone ask "what do we do with incomplete stories at the end of the Sprint" when calculating velocity.

Initially I thought there were a quite a few options, but after clarifying what velocity is and giving it some thought it became clear that there was only a couple of legitimate ways.

Sprint Velocity Defined

Sprint Velocity pretty much boils down as the sum of completed PBI estimates delivered at the end of a Sprint. It is a planning tool that can be used to quickly establish a rough but reliable capacity for an upcoming sprint. 

"Velocity is calculated at the end of the Sprint by totalling the Points for all fully completed User Stories."

Scrum Inc.

"At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity."

Agile Alliance

"Velocity is the sum of the estimates of delivered (i.e., accepted) features per iteration."

Version One

Velocity in Scrum

Scrum doesn't actually prescribe the use of velocity, but it is probably the most popular Sprint Planning tool due to it's simplicity and effectiveness.

Dealing with Incomplete Stories

What to do

Discard the whole estimate and re-estimate for a subsequent sprint

This gives the total estimate of completed (start to finish) PBIs in the Sprint, which tells the team how much it can realistically complete in one sprint.

This is the only approach that conforms to the definition of velocity.

Carrying over the original estimate into a subsequent sprint

Totalling the estimates of PBIs finished in the Sprint is an easy approach to take however this will only reliable tell you how how much work can be finished in a sprint. This might sound good and easy to do but what you can end up with is a highly unpredictable metric which can change significantly between sprints as the team fails to deliver a bulk of the work in one sprint (trough) only to finish it all of in the next (peak).

As this is really looking at finished PBI estimates this isn't Sprint Velocity (as tasks being counted were half completed in the last sprint).

However, if you are taking an average, of say that last 3 sprints, you can mitigate this peak and trough effect.

What to avoid

The following metrics should be avoided as they don't really represent Sprint Velocity as they aren't totalling estimates of completed stories.

Counting the whole estimate in the current sprint and create a new task to complete the work

Doing this means that you are counting the total estimate of PBIs that were started in the sprint. This isn't particularly meaningful as you can start as many as you want, it doesn't tell you how much you can actually do in the sprint.

Split the estimate into 2 PBIs (complete/incomplete estimates)

Splitting a PBI into two and and roughly distributing the estimate relies on the team accurately (or representationally) splitting the estimate. This does give you a rough figure which represents how much estimated work can be spent in the Sprint, but is less useful as you could finish the sprint with 50% of the work actually "done". There might be a temptation to use this approach but it adds more complexity to give you what is actually less meaningful data.

Include PBI estimate in the current sprint then create and estimate a new task to complete the work

This will give you total amount of estimated work that was started in the Sprint, plus the additional estimates of work carried over from the last sprint, which is double counting making the data largely meaningless.

Summary

In short, if you are counting the estimates of incomplete stores then what you have is not actually measuring Sprint Velocity.

This is not to say that using other metrics or other planning techniques are wrong or unacceptable, but that velocity has a single meaning.

References and Further Reading