Engineering Initiative Progress: Tracking Major Work Across Many Sprints
Sprints are two weeks long. Initiatives last quarters. The hardest part of engineering leadership reporting is connecting the two: which initiatives each sprint actually advanced, and whether each initiative is moving, growing or stuck.
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.
How this is calculated: Engineering complete is not delivered in the methodology
The initiative hierarchy
Most organisations track large work in three levels:
| Level | Typical Jira representation | Horizon |
|---|---|---|
| Initiative | Advanced Roadmaps “Initiative” issue type, Parent Link, or a custom field | Quarter or longer |
| Epic | Epic issue type; children via Epic Link or Parent | Several sprints |
| Story / Task / Bug | Work items in sprints | Days |
Advanced Roadmaps is not required. If the only hierarchy in Jira is epics, track epics; if an initiative field exists, group epics under it. Degrade gracefully rather than inventing structure.
Why initiative tracking is hard
Sprint reports answer sprint questions: did the plan hold, what carried over. Roadmap tools answer roadmap questions: what is planned, when. Neither answers the leadership question in between — what major initiatives are we investing in, and are they actually moving?
Two misleading conclusions are common. An initiative looks stagnant when its scope is actually expanding. And a team looks slow on an initiative when a large share of its sprint is going to other initiatives, bugs, support or technical debt. Both are resolved by connecting initiatives to sprint data, not by asking the team for a status update.
The measures that connect initiatives to sprints
| Measure | Calculation | Answers |
|---|---|---|
| Sprint contribution | Completed work in the sprint belonging to each epic ÷ all completed work | What did this sprint deliver? |
| Epic progress | Engineering-complete ÷ current scope of the epic | How far along is it? |
| Production release | Released ÷ current scope of the epic | Has it reached customers? |
| Scope growth | Change in epic scope over a period (needs history) | Is it getting bigger? |
| Epic carryover | Epic issues unfinished at sprint close ÷ epic sprint work | Is it accumulating WIP? |
| Investment share | Epic’s share of sprint work over several sprints | Is priority shifting? |
Roll epics up to initiatives by summing their work. Keep “no epic” as its own line: work that is not linked to any initiative is part of the answer, not noise to discard.
Sprint work vs epic progress
Keep these apart in every report. “Application Workflow: 14 issues handled in Sprint 18, 8 completed” is sprint work. “47 issues total, 29 completed, 62%” is epic progress. Mixing them produces statements that are true and useless.
How to interpret an initiative portfolio
Completed work rose every sprint — but scope rose faster, so the remaining gap grew from 18 to 23 issues.
Plot completed work against total scope: if scope climbs as fast as work completes, the epic is busy but not getting closer.
- High investment, low progress change — check scope growth before concluding the work is slow.
- Falling investment — confirm the shift in priority was intentional.
- Rising carryover and recurring WIP — the initiative is starting more than it finishes.
- Long, thin timeline rows — an epic worked a little in every sprint for months often lacks a clear finish line.
- Recently started, near completion — neutral lifecycle signals, useful for planning conversations.
Limitations
Initiative data is often incomplete: epics without a Parent Link, initiatives maintained in a spreadsheet, or custom fields that differ per project. Current-state exports cannot show when epics moved between initiatives. Treat initiative roll-ups as descriptive, and show which epics have no initiative instead of forcing them into one.
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.
Common mistakes
- Ranking initiatives by progress. Initiatives differ in size, risk and discovery. Show them side by side, not in a league table.
- Red / amber / green status without rules. A colour hides the reason; a documented signal (“scope grew 30% in three sprints”) shows it.
- Dropping unlinked work. A 25% “no epic” share is a planning signal.
- Rolling up points across teams. Point scales are team-specific.
Leadership implications and questions to ask
Initiative reviews go better with a fixed set of views: portfolio (progress, scope change, sprint investment, carryover), investment trend, and one drill-down per initiative. Rotate through them every month; the goal is to notice change early, not to grade teams.
Questions worth asking
- Which initiatives did the last three sprints actually advance?
- Has engineering priority intentionally shifted away from any initiative?
- Is any initiative’s scope growing faster than its completed work?
- Should the work with no epic be associated with an initiative, or does it represent operational or unplanned demand?
Example
A portfolio review shows Business Profile at 72% with +12% scope change, 18 issues this sprint, 2 carried over. Application Workflow is at 61% with +31% scope change and 6 carried over, 4 of them recurring. Reporting is at 35% and was 17% of the last sprint’s work, up from 4% three sprints ago.
None of these is a verdict. Together they point to three conversations: whether Application Workflow’s scope is under control, what is keeping its recurring issues open, and whether the jump in Reporting investment was a decision or a drift.
Related metrics and how the Epic Delivery report helps
See it on your own data in the Epic delivery report.
Related guides: engineering investment allocation, Jira epic reporting, epic carryover and engineering capacity planning.
The Epic Delivery report builds the initiative → epic → issue hierarchy from Epic Link, Parent and Parent Link fields (whichever exist), shows a portfolio view without rankings, an epic sprint timeline, sprint contribution and investment trend, and documented attention signals for each epic.
Frequently asked questions
- Do I need Jira Advanced Roadmaps to track initiatives?
- No. If initiatives exist (via Parent Link or a custom field), group epics under them; otherwise track epics directly. The analysis should degrade gracefully.
- How do I connect initiatives to sprint data?
- Attribute each sprint’s work to its epic, and each epic to its initiative, then sum. Keep work with no epic as its own category rather than discarding it.
Related guides
Engineering investment allocation
How to measure engineering investment allocation from Jira — strategic initiatives, features, bugs, technical debt, support and operational work — why it matters, and how to keep it from becoming a productivity metric.
Jira epic reporting
How to build a high-level Jira epic report that combines progress, scope growth, sprint investment, carryover, WIP and delivery flow — and avoids the two most misleading conclusions in initiative reporting.
Epic carryover
Epic-level carryover explained: sprint carryover by epic, recurring WIP, carryover age, why the same issues repeatedly carrying matters, and the questions engineering leaders should ask.
Jira epic progress
How to measure Jira epic progress honestly: issue-count and story-point progress, status distribution, why percent complete misleads when scope grows, and how carryover and WIP change the picture.