Incomplete work at the end of a sprint — what actually to do

Inevitably, a development team will pull in too much work for a sprint — or produce work that doesn’t meet the definition of done. What should be done with those incomplete PBIs? This debate comes up constantly. Here’s how I handle it and why.

First, a reminder about velocity

Velocity is the measure of the rate at which a team delivers done items from the product backlog. It’s how much value is delivered per iteration — the sum of effort points for all PBIs that meet the definition of done.

That definition matters. Velocity isn’t effort expended. It’s value earned.

So what do we do with incomplete items?

The Scrum Guide doesn’t give a precise answer for normal sprint operations (it addresses cancellations specifically). My approach: treat incomplete items the same way the guide treats cancelled sprint work — re-estimate and put them back in the backlog.

In practice, since the incomplete items are usually still the highest priority, they get pulled back into the next sprint. The team doesn’t receive velocity credit for them, because no value was delivered.

This is where I consistently get pushback: “But we did work on those items — don’t we get credit for the effort?”

No. And here’s why that framing is the problem.

Velocity is a measure, not a goal

When a team asks for “credit” for incomplete work, they’re revealing that they’ve started treating velocity as a goal rather than a measurement tool. That’s backwards. Velocity exists to help with release planning and to signal whether a team is improving. Inflating it to reflect incomplete work corrupts both uses.

The Agile Manifesto is clear: working software over comprehensive documentation. A team that’s more focused on their velocity number than on delivering done, shippable increments has lost the plot.

The practical exception

That said — if incomplete items genuinely become a recurring bone of contention on your team, you can track the original effort estimate alongside the re-estimate. As long as you use average velocity for planning, the math works either way. The cost is a slightly more complex tracking process; the benefit is a team that feels heard.

Pick your battles. Culture matters more than precision in velocity accounting. But don’t let the exception become the rule — and don’t let velocity become a goal in itself.

The goal is done software. Full stop.