VeloWiseengineering delivery intelligence

WIP Debt: When Carryover Becomes the Same Work, Sprint After Sprint

Some carryover is healthy. Carrying the same issue into its fourth consecutive sprint is not — it is a decision nobody has made. WIP debt measures how much of a sprint’s carryover is made of work that has carried before.

For: Engineering Managers, Team Leads, Scrum Masters, Product OwnersUpdated
One-time vs chronic carryoverExample delivery data

One-time carryover — carried once, then finished

  1. Sprint 10
  2. Sprint 11

Chronic carryover — carried three sprints in a row

  1. Sprint 8
  2. Sprint 9
  3. Sprint 10
  4. Sprint 11

WIP debt is carryover that keeps carrying — work the team keeps paying for sprint after sprint.

How this is calculated: One-time vs chronic carryover in the methodology

What WIP debt is

Carryover age is the number of consecutive sprints an issue has been in, ending with the current one. An issue in its first sprint has age 1; one that has carried three times is in its fourth sprint and has age 4. If an issue went back to the backlog between sprints, the count restarts.

Recurring carryover is carried work with age 2 or more: it had already carried at least once before this sprint. WIP debt is recurring carryover as a share of all carried work.

WIP debt = carried issues already in ≥ 1 earlier consecutive sprint ÷ all carried issues

The name is deliberate. Like financial debt, recurring WIP accrues interest: every sprint it stays open, it occupies planning time, status meetings, context and often a slice of someone’s attention — without delivering anything.

Why it matters

Carryover that consists of fresh work is a timing problem — the sprint ended before it did. Carryover that consists of the same issues every sprint is a decision problem. Something about those issues is not working: they are too large, blocked on something nobody is chasing, lower priority than the sprint admits, or waiting for a clarification that is never coming.

WIP debt also hides inside capacity. A sprint that starts with 15 points of recurring carryover has 15 points less room than its plan assumes, and because the work “was already planned”, it is rarely questioned. Growth in recurring carryover is one of the six persistent carryover patterns — see why work carries over.

How to calculate it from Jira

Every Jira export includes the multi-value Sprint field: the list of sprints an issue has been in. That is enough to calculate carryover age without any change history.

  1. Order sprints by start date.
  2. For each issue carried out of the sprint (or unfinished, for an active sprint), walk backwards from the current sprint while the issue was in each previous sprint. The number of steps is its carryover age.
  3. Group carried issues by age: 1, 2, 3 and 4+ sprints.
  4. Divide the carried issues with age ≥ 2 by all carried issues (or use points).
Carryover ageWhat it usually means
1 sprintTiming — started late, finished just after close
2 sprintsWorth a look at planning — is it on track now?
3 sprintsSomething is structurally wrong: size, dependency or priority
4+ sprintsA decision is overdue: split, finish first, or return to the backlog

Carryover age is not issue age

Issue age — days since the issue was created — is a different measure. An issue created six months ago may be carrying for the first time, and a week-old issue can already be in its third sprint on a one-week cadence. Show both, but do not mix them up.

How to interpret it

Count vs ageExample delivery data

Code review · Team A

0–2 days6
3–5 days4
6–10 days8
10+ days11

29 issues — and 19 of them older than 5 days.

Code review · Team B

0–2 days18
3–5 days4
6–10 days1
10+ days0

23 issues — nearly all fresh and moving.

How many issues sit in a stage says little; how long they have been there — against the team’s own history — says a lot.

  • WIP debt under ~20%: most carryover is fresh; focus on timing and scope.
  • 20–40%: a meaningful share of carried work is stale. Review it at planning.
  • Over 40%, with three or more recurring issues: the backlog of stale work is shaping every sprint.
  • Rising recurring counts over consecutive sprints matter more than any single value — that is WIP accumulating.

Look at what the recurring issues have in common: size, work category, the stage they were in at close, or a shared dependency. The pattern usually points at the fix.

Apply this to your team’s delivery

Create a free account, set up your organization and project, then import a Jira CSV. Start with the available evidence; add sprint dates and history for stronger analysis.

Create Free Account Try sample project

Common mistakes

  • Re-planning recurring work by default. Moving it forward is a decision too; make it explicitly.
  • Resetting the clock by cloning issues. Cloning a stale issue into a new one hides the debt without paying it.
  • Counting age from creation date. That measures backlog age, not carryover.
  • Blaming the assignee. An issue that carries four times is usually blocked, oversized or deprioritised — a planning problem.

How to pay WIP debt down

  1. Review every issue with carryover age ≥ 2 at sprint planning. For each: finish first, split, unblock, or return to the backlog.
  2. Finish before starting. Put recurring carryover at the top of the sprint and hold new work until it moves.
  3. Split large items. An issue that repeatedly carries “in development” is often two or three issues.
  4. Chase the blocker. Recurring issues in Blocked or Clarification need an owner outside the team.
  5. Plan total demand, not new work. Carryover in belongs in the capacity calculation — see small-team sprint planning.

Questions to ask

  • Are the same issues repeatedly carrying between sprints?
  • Who decides what happens to an issue that has carried three times?
  • Is recurring work blocked, oversized or just lower priority than we admit?

Example

A sprint closed with 9 issues carried over. Five were in their first sprint, two in their second, one in its third and one in its fifth. Recurring carryover: 4 issues. WIP debt: 4 ÷ 9 = 44%. Over the previous three sprints recurring carryover had gone 1 → 2 → 4.

At planning, the team split the fifth-sprint issue into three stories, escalated the third-sprint issue’s external dependency, and returned one second-sprint issue to the backlog. Recurring carryover dropped to 1 the following sprint.

Related metrics and how the Workload & Carryover report helps

See it on your own data in the Workload & carryover report.

Related: Jira carryover, aging WIP, how to reduce sprint carryover and why work carries over.

The Workload & Carryover report calculates carryover age for every carried issue from the Sprint field, groups carried work into 1, 2, 3 and 4+ sprints, shows WIP debt and its trend, and lists each issue with the consecutive sprints it has been in. The carryover view adds carry-in and carry-out rates per sprint.

Frequently asked questions

What is WIP debt?
The share of a sprint’s carried-over work that had already carried over at least once before. High WIP debt means carryover is made of the same stale issues, not fresh work that just ran out of time.
How do I find issues that keep carrying over in Jira?
Use the multi-value Sprint field in a Jira export: count how many consecutive sprints each unfinished issue has been in. Issues in three or more consecutive sprints need a decision.