Undone Work: A Monkey on the Scrum Team’s Back

In Scrum, “Done” means done. Not halfway done, not “almost there,” and certainly not “we’ll get to it next Sprint.” Yet, many teams find themselves with a growing burden of unfinished work. Over time, that burden starts to feel like a monkey on the team’s back—heavy, distracting, and hard to shake off.

The Cost of Carrying Over

Some teams fall into the habit of pulling work into the Sprint even when they know they probably won’t finish it by the end of the Sprint. “We’ll try our best,” they say, or “it’s fine if it carries over to the next Sprint.” But it’s not fine. That undone work becomes like a snowball you're pushing uphill — it gets heavier the farther you go. Eventually, it’s so large and burdensome that it slows the team down, clouds transparency, and makes it nearly impossible to inspect and adapt effectively.

In one team I observed, nearly 70% of their work carried over from one Sprint to the next. Sprint Planning became an exercise in futility. There was no real commitment, just a rolling to-do list. And because so much of the work never reached “Done,” stakeholders had little visibility into what the Scrum team was working on, or when they would really deliver something usable.

Don’t Pull It In Unless You Can Finish It

Scrum is clear: don’t pull work into a Sprint unless the team believes it can get it to “Done.” It’s not about optimism—it’s about a commitment to deliver a done increment that meets the Sprint goal.

In addition, if something unexpected happens and work doesn’t get finished, it shouldn’t just roll into the next Sprint by default. That work should be resized and returned to the Product Backlog, where the Product Owner can decide whether it's still the most valuable thing to do next. Why? Because new opportunities may have come up. Priorities might have changed. Assuming that unfinished work should automatically carry forward undermines the role of the Product Owner and weakens the team’s agility.

When There’s Time Left Over

Sometimes, developers wrap up their work early and feel tempted to pull in something new. That’s fine—but only if it’s intentional. Teams often create a working agreement to handle this situation better. Before pulling in more work, they might ask:

1. Does anyone else need help?

2. Are we on track to deliver a done increment that meets the Sprint goal?

3. Is there any technical debt I can address?

4. Is there any training I can do?

5. Are there any bugs or small process improvements I can tackle?

6. Is the work I want to pull in small enough to be completed within the remaining time in the Sprint?

7. Have I consulted the Product Owner to see if this is the most important thing to do next?

If the answer to any of these questions is 'no', then the work should not be added to the Sprint in progress.

Fixing the Root Cause

If undone work is a recurring issue, don’t just accept it. Bring it to the Sprint Retrospective and talk about it. Common solutions include:

• Sizing work smaller – Break down backlog items into thin vertical slices that can be completed within a few days.

• Pulling in less work – Don’t overload the sprint with optimistic guesses. Use past performance (velocity or throughput) as a guide.

• Pair programming – Two heads are often better than one, especially to unblock sticky work.

• Limiting work in progress – The more the team juggles, the less they finish. Focus leads to flow.

  
  

Let Go of the Monkey

Carrying over undone work should not be the norm. Scrum is designed to help teams deliver value in small, usable increments. When work doesn’t get to “Done,” it disrupts that rhythm. The monkey on your back doesn’t just slow you down—it keeps you from seeing clearly where you are and where you need to go.

If your team is struggling with carryover, make a change. Get that monkey off your back—and start finishing what you start.