Why portfolio predictability needs a layer Jira was never built to provide
- Jira tracks execution for one team at a time. It has no field for "this ART" or "this value stream," so it structurally cannot answer a portfolio-level question — that isn't a bug, it's scope.
- The portfolio question — does what this group has committed to still fit the estimate the roadmap was built on? — is an audit, run on a cadence, comparing two numbers. No delivery tool is built to run audits.
- Capasight is a read-only layer next to Jira that names the groups Jira can't see, rolls their work up, and checks it against the original estimate continuously, using data that's already in Jira.
The Problem: Jira Tracks Teams. It Doesn't See the Portfolio.
Jira isn't broken when a portfolio drifts — it's being asked a question outside its job description. When a portfolio stops being predictable, the first thing that gets blamed is the tool. If only Jira did cross-project roadmaps properly. If only the reports rolled up. If only there were a field for the thing above a team.
Most of the time, Jira is doing exactly what it was built to do. It records work against one team at a time, moves it through a workflow, and reports on execution. On that job it's very good — "is this team's sprint full?" has a clean answer, right there.
The portfolio question is a different shape entirely. It isn't about one team or one item. It's: what has this group — this ART, this value stream — taken on, collectively? And does the work it has committed to still fit the estimate the plan was built on?
Jira can't answer that, and it's fair that it can't. There's one Team field and nothing above it, so "this group" isn't something Jira can see. Early in a programme increment, most of the work hasn't reached a team yet — it sits with the ART, waiting to be broken down — so a leader who wants to know what the group has taken on assembles it by hand, every time.
Key terms this article uses:
| Term | What it means here |
|---|---|
| Team | The one grouping Jira natively tracks work against |
| ART (Agile Release Train) | A group of teams working toward a shared value stream; no native Jira field |
| Value stream | The grouping above an ART; also has no native Jira field |
| Portfolio reconciliation | Comparing the original top-down estimate against the current bottom-up backlog, at any of these levels |
And reconciling the early estimate against emerging work isn't a delivery activity at all — it's an audit. It asks the plan and the backlog to agree, on a cadence, in front of the same person. Nothing in a delivery tool's job description says it should do that.
How to Check for This Gap in Your Own Portfolio
- List every ART or value stream your organisation actually plans around — whether or not Jira has a field for it. Most enterprises have this structure informally even without SAFe terminology.
- For each group, total the story points or feature-level estimates currently rolled up beneath it — the bottom-up number, as it stands today.
- Pull the original portfolio-level estimate — the t-shirt size or budget figure the roadmap was actually built on, before any stories existed.
- Compare the two. Where they still agree, there's nothing to do. Where they've diverged, that's the finding — not a mistake by anyone, just work that's been refined past the number the plan assumed.
- Repeat on a cadence, not once. A one-time check tells you where you stand today; a recurring one is what catches drift while it's still cheap to fix. This is the step manual reconciliation usually skips, because assembling the numbers by hand is too expensive to do every sprint.
Manual Reconciliation vs. a Purpose-Built Layer
| Spreadsheet / manual rollup | Capasight | |
|---|---|---|
| Data source | Exported from Jira, re-entered by hand | Read directly from Jira, live |
| Update cadence | As often as someone has time to rebuild it | Continuous |
| Effort per cycle | Hours, repeated every PI or sprint | None — it's already running |
| Who can see the answer | Whoever built the spreadsheet | Every level of the org that needs it |
| Write access to Jira | N/A | None — read-only by design |
| Risk of stale numbers | High — accurate the day it's built, stale the next | Low — always current |
FAQ
Does Capasight replace Jira? No. Capasight is a read-only layer that sits alongside Jira. It doesn't write back to your issues or change your workflow — it names groups Jira can't natively see (ARTs, value streams) and checks their work against the original estimate.
Is "portfolio reconciliation" a SAFe-only concept? No. Any organisation that plans in groups larger than a single team — regardless of framework — hits this gap. SAFe's ART and value-stream vocabulary just gives the grouping a name.
Why doesn't Jira just add a field for this? It could, but the harder problem isn't the field — it's the comparison. Even with a group field, someone still has to check the group's current backlog against the estimate the plan was built on, on a recurring cadence. That comparison is the audit function Capasight runs.
How often does Capasight check for drift? Continuously, from the data already in your Jira instance — not on a manual export-and-rebuild cycle.
Does this require new fields or process changes on my teams? No new fields are required to start. Capasight reads what's already there; it will surface where sparse data (like missing start dates) limits what it can tell you, which is itself useful information.