What happens if the development team Cannot complete all Sprint backlog items by the end of the sprint?

As well-intentioned as teams are, it’s really hard to finish absolutely everything by the end of a sprint. A team may have grabbed eight product backlog items (typically user stories), but only finish six or seven of them. The other items are often close to done, but this isn’t horseshoes so close doesn’t count.

But what about the estimates on those unfinished product backlog items? Should they be re-estimated? And should the team get partial credit for the work they did complete? Let’s consider each of these questions, starting with partial credit.

Should a Team Earn Partial Credit?

When a team finishes part of a story, team members often ask to receive partial credit toward their velocity. For example, a team that claims to be half done with an eight-point product backlog item may expect to count half of that—four points—toward their velocity.

This is a bad idea. A team should earn credit only for work that is truly done. In this example, nothing yet meets the team’s definition of done. Work is only half done. Taking credit for partially done work would be like me inviting you over for dinner and serving you half-cooked chicken. It might taste OK now, but you’re going to regret it later.

When a team takes credit for partially complete work, they often overestimate how much is done. There is a joke in the software development profession that says software development projects are 90% done for 90% of their schedule.

This is because developers think they see the full scope of what’s needed and they are truly 90% done with that. But as they work to finish the last 10%, they realize the solution is bigger than they thought—and even after more work they are still just 90% done with the bigger scope.

So a team that says they’re 50% done is perhaps only 40% or 48% or 35% done. Knowing the percentage done is very hard and most of us overestimate how done we are.

Because teams tend to think they are further along than they truly are, velocity is slightly inflated. An inflated velocity feels good at the moment—like my half-baked chicken—a team can tell its stakeholders a nice, big, juicy velocity value. But that inflated velocity will stop feeling good if anyone ever uses that artificially high velocity to predict when the next project will be done.

No Partial Credit

I advise teams to take a stance of no partial credit. No matter how close team members are to finishing a backlog item, they earn no points for it until the entire item is done. This is analogous to scoring a touchdown in American football. In American football, a team needs to move the ball 100 yards down the field, getting into their opponent’s end zone. Doing so earns a team six points (and the opportunity to earn one or two additional points).

Moving the ball 99 yards earns the team…zero points. No partial credit.

The Benefits of a No-Partial-Credit Stance

There are two big benefits to taking a stance of no partial credit. First, team members will seek to work on smaller product backlog items in the future.

A team doesn’t care if their Scrum Master refuses them partial credit on a one-point story. They do care when they can’t take partial credit on an eight-pointer. Most teams will respond to not getting partial credit by splitting items into smaller discrete pieces of work.

Second, when not allowed to take partial credit, many teams resolve to try harder to complete the items they bring into a sprint. That’s great—we want that.

When I refrain from allowing a team to claim partial credit, it’s a double win: the team brings smaller items into their sprints and they focus more on finishing them. What’s not to like?

Having resolved that a team should not earn partial credit for an incomplete product backlog item, let’s turn our attention to whether that unfinished item should be re-estimated.

Re-Estimating Unfinished Work

When a product backlog item is unfinished at the end of an iteration, the team often wants to know if the item should be re-estimated. This is independent from the issue of wanting partial credit. After all, team members reason, at least some work has been done and so the estimate of remaining work may have changed.

In fact, the size of the product backlog item may have increased such that the estimate of what remains actually goes up and is higher than the initial estimate. For example, a team feels like they’ve made two points of progress on a five-point story but also have discovered that there are eight points remaining. In re-estimating partially finished work, it is entirely possible for the new estimate to exceed the original.

But should a team re-estimate at all?

Reasons to Re-Estimate

There are two arguments in favor of re-estimating:

1. It’s more accurate since some part of the work has been performed
2. It’s necessary to plan the next sprint

It’s hard to argue with the first point, so I’ll accept that. The second point is where things get interesting. Team members will say they can’t decide how much work to bring into a sprint if some of the backlog items have outdated estimates because they are partially complete.

For example, suppose a team has room for five more points in a sprint. An eight-point story won’t fit. But what if the team thinks approximately half of the eight-point story was finished in the just-completed sprint? It sure seems like half the item could fit in the next sprint. Should it then be re-estimated at four or five points to indicate that it fits?

My opinion is that no, it should not. That is: leave the original estimate alone and bring the item into the sprint if the team thinks it fits.

The argument for resizing the backlog item assumes the team is doing velocity-driven sprint planning. In that approach a sprint is planned by selecting product backlog items whose estimates sum to the team’s average velocity. So if a team has a velocity of 30, they bring in 30 points of work. If they’ve already brought in 25 and the next item is a partially finished item estimated at eight points, that item won’t fit.

But for a variety of reasons, I don’t think velocity-driven planning is the best approach to sprint planning. I far prefer capacity-driven sprint planning, which involves the team simply selecting items one at a time and seeing if the item can be done in the sprint. If they can, they include it and consider another until the sprint is full.

Capacity-driven sprint planning uses velocity but is not driven by it. Teams using this approach aren’t constrained by pulling in exactly what their velocity says they should. And so a team doing capacity-driven sprint planning will take into account the finished portion of that eight-point story when they decide whether the story will fit in their sprint.

Focus on Average Rather than Actual Velocity

In general, teams will do better if they pay a bit less attention to each sprint’s velocity and more to the average velocity of recent sprints. In the approach I’m advocating, a team can feel cheated out of a few points of velocity in one sprint since they aren’t able to claim partial credit. But, since the item is not re-estimated, they’re getting full credit for the work in the following sprint. It all comes out in the end.

In the example of the eight-point story that is half done, the team claims zero points of velocity credit in the first sprint despite doing perhaps three or four points of work. But they get all eight points in the next sprint. This means the average velocity for those two sprints will be exactly as one would expect.

The Sole Time to Re-Estimate Partially Finished Items

Re-estimating partially finished product backlog items is unnecessary work. There is one situation, however, in which it’s advisable. A team should re-estimate a backlog item that is being put back on the product backlog and will not be finished in the next iteration or two. In that scenario it makes sense to determine a reasonable split of the item, give the team some credit for the work done, and return the item to the backlog with a good estimate of the work remaining.

In all other cases, though, a team will do well to not take partial credit and not bother re-estimating, especially if the team is doing capacity-driven sprint planning.

What Does Your Team Do?

What does your team do with unfinished work? Do you re-estimate it? Do you take partial credit? Do you never, ever, ever have anything unfinished? Please share your thoughts in the comments below.

None of these answers are good.

Generally, this question seems to be about the Scrum Team's outputs rather than the outcomes enabled by the work completed in the Sprint. The Sprint's purpose is not to complete Product Backlog Items or tasks but to achieve the Sprint Goal. To ensure visibility and transparency, there should be a connection between the Sprint Goal, some of the selected Product Backlog Items, and how the Product Backlog Items are decomposed during Sprint Planning. There's no mention of the Sprint Goal in any of the answers.

Looking into the answers, they are all wrong.

A is incorrect because the implication is that the Definition of Done will be relaxed to allow the work to be considered Done. Relaxing the Definition of Done is the same as decreased quality, and "quality does not decrease" during a Sprint. The best time to review the Definition of Done is at the Sprint Retrospective, so the updated Definition of Done can guide the next Sprint Planning. I'd also hold that quality should not decrease between Sprints, either, so changes to the Definition of Done should not lead to a decrease in the quality of the work performed.

B is wrong since working extra time goes against working at a sustainable pace. Not only is a sustainable pace a part of Scrum, where it promotes focus and consistency, but it's a principle of Agile Software Development.

C is the closest to being right, but it is still wrong. Incomplete Product Backlog Items do return to the Product Backlog, but this happens at the end of a Sprint. The nuances of how this is done depend on the tools being used, but knowing what work was complete, started but incomplete, or not started is useful to facilitate discussions at the Sprint Review and Sprint Retrospective. The team should not remove the Product Backlog Items from the Sprint Backlog until the end of the Sprint, at which point the Product Owner can determine if they are still relevant and order them with the other Product Backlog Items for a future Sprint.

D is incorrect because C is partially right. Work does not roll over automatically between Sprints. Incomplete work must be brought into the next Sprint at Sprint Planning, even if it is started or partially complete. If the work is not valuable, it could end up lower in the Product Backlog or even removed entirely. The Product Owner needs to work with the Developers to weigh the work's state, the cost of incomplete work, and the value of doing the work to decide how it is ordered.

Given the poor quality of the question and answers, I'd also be suspect of the quiz and any training or certifications offered by this organization. It doesn't seem to align well with the Scrum Guide. Looking through the link provided, there are several questions that I disagree with, based on the last two revisions to the Scrum Guide. I'm not sure the answers were ever correct according to the Scrum Guide.