VeloWiseengineering delivery intelligence

Epic Carryover Across Sprints: When Initiatives Accumulate Unfinished Work

Carryover is usually reported per sprint: how much did not finish. Viewed per epic, it answers a sharper question: which initiatives keep accumulating unfinished work — and which issues have been “almost done” for four sprints?

For: Engineering Managers, Directors of Engineering, Technical Program Managers, Scrum MastersUpdated
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

An epic that keeps carrying the same issues is not progressing, however busy its sprints look.

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

Sprint carryover, recurring WIP and epic carryover

  • Sprint carryover — work unfinished when a sprint closes, moved to the next sprint or back to the backlog.
  • Recurring WIP — carried issues that had already carried from an earlier consecutive sprint. See WIP debt.
  • Epic carryover — the same measures restricted to one epic’s issues in a sprint: what it committed, completed and carried.
Epic carryover rate = epic issues carried out ÷ epic sprint work
Carryover age       = consecutive sprints an issue has been in, ending now

Why epic-level carryover matters

A team-level carryover rate of 25% hides where it comes from. Often most of it belongs to one or two epics: an integration blocked on a partner, a feature whose testing keeps slipping, a large story nobody has split. Epic carryover points the conversation at the initiative instead of the whole team.

The same issues repeatedly carrying matters more than the rate. An issue in its fourth consecutive sprint has consumed planning, stand-ups and context four times without delivering. It is rarely a speed problem; it is a decision that has not been made.

How epic carryover compounds

Carried work enters the next sprint before any new work does. When an epic carries 12 points and the plan adds another 30 points of new stories for the same epic, the epic’s real demand that sprint is 42 points — usually more than it has ever completed in one sprint. The next sprint carries again, and the epic’s progress percentage creeps while its sprint investment stays high. Leaders see an initiative that is “getting lots of attention but not moving”. The fix is not more attention: it is planning the epic’s existing WIP first, and adding new epic work only into the room that remains.

How to calculate epic carryover from Jira

  1. For each closed sprint, take the issues in the sprint at close and group them by epic (Epic Link or Parent).
  2. Count completed within the sprint window and carried out (unfinished at close).
  3. For each carried issue, count consecutive sprints from the multi-value Sprint field.
  4. Group carried issues into 1, 2 and 3+ sprints; recurring = 2 or more.

The Sprint field is in every Jira export, so carryover age needs no change history. Epic membership in past sprints is best taken from Epic Link or Parent history; without it, current membership is used and moves between epics are invisible.

How to interpret it

Engineering complete is not deliveredExample delivery data

Business Profile epic

Development complete
92%
QA complete
68%
Released
42%

Engineering completion ≠ production delivery. Development complete counts work past development; QA complete counts done and released; released counts only what reached production.

A Jira “% done” can say 92% while only 42% of the epic has reached customers — delivery has milestones after engineering.

  • High rate, no recurring issues — the epic’s sprint work was too large for the sprint; fresh work ran out of time.
  • Recurring issues present — specific items are stuck. Read them: blocked, oversized, or deprioritised?
  • Carryover concentrated in Testing or Review — work is built but queued downstream; see engineering bottlenecks.
  • Carryover plus scope growth — new work is being started before existing work finishes.

Limitations

Carryover depends on sprint dates to decide what completed inside the sprint. Stage at close for older sprints needs status history. And carryover counts issues, not effort: one carried 13-point story matters more than three 1-point ones — switch to points to see it.

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 issues by default. Moving them forward again is a decision; make it explicitly.
  • Cloning stale issues to reset their age. It hides the debt without paying it.
  • Blaming assignees. An issue that carries four times is almost always blocked, oversized or deprioritised.
  • Reading one sprint. Look at the trend and at recurring issues together.

Leadership implications and questions to ask

Review each epic’s recurring issues at sprint planning: finish first, split, unblock, or return to the backlog on purpose. Plan the epic’s new work only after existing WIP is accounted for.

Questions worth asking

  • Are we committing new epic work before resolving existing WIP?
  • Which issues in this epic have carried three or more times, and what is blocking each?
  • Is work reaching testing faster than it can move through validation?
  • Should the stuck work leave the epic so the rest can finish?

Example

In Sprint 18, Application Workflow committed 31 points, completed 19 and carried 12: a 39% carryover rate. Of its carried issues, five were in their first sprint, three in their second and two in their third or later. PROJ-142 had been in Sprints 15, 16, 17 and 18 — a four-sprint carryover — blocked on a vendor API.

The team escalated the vendor dependency, split PROJ-142 so the unblocked part could ship, and planned no new Application Workflow stories until the two oldest items moved.

Related metrics and how the Epic Delivery report helps

See it on your own data in the Epic delivery report.

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

The Epic Delivery report shows each epic’s committed, completed and carried work for any sprint, groups carried issues by carryover age, lists recurring issues with the sprints they have been in, and flags “Recurring carryover” with its rule. The Workload & Carryover report shows WIP debt across the team.

Frequently asked questions

What is epic carryover?
The share of an epic’s sprint work that was unfinished at sprint close, plus how long those issues have been carrying. It shows which initiatives accumulate unfinished work.
Why do the same issues keep carrying over?
Usually because they are blocked, too large for a sprint, or lower priority than the plan admits. Each needs a decision: unblock, split, finish first or drop.