A three-layer guide to portfolio management in Jira: native boards and Plans, marketplace roadmap apps, and the investment governance layer neither covers.
Jira project portfolio management means planning, tracking and governing many projects at once, so an organisation can see where its delivery capacity is going and decide whether it should keep going there. A single Jira project answers for its own backlog. A portfolio answers for the money.
The distinction matters because Jira was not built for the second job. It began as an issue tracker for one team's work, and it remains very good at that. Everything portfolio-shaped arrived later, in layers. If running portfolio management in Jira has landed with you — you lead the PMO, or you own Jira and the CFO wants to know what all those licences produce — you are really evaluating three layers. What Jira ships natively. What the marketplace roadmap apps add. And a governance layer that neither of them keeps. Most of what is sold under the label Jira PPM lives in the first two.
Start with what is already paid for. Every Jira project gives a team a backlog, a board and a workflow. Dashboards and saved filters let you assemble cross-project views by hand, and JQL will slice issues any way you like. For a small portfolio, a dashboard of filter gadgets is a legitimate answer, and plenty of PMOs run on exactly that.
The purpose-built layer is Plans, previously called Advanced Roadmaps, included in Jira Premium and Enterprise. Plans pulls issues from multiple projects and boards into one timeline, models dependencies between them, adds hierarchy above the epic, and sketches capacity against teams and sprints. It supports scenario planning, so you can test a reshuffle before you commit to it. For the scheduling half of portfolio management — what is happening, in what order, blocked by what — Plans is a serious tool and an underused one.
Notice what it holds, though. Plans aggregates the delivery schedule. It knows when epics start and finish. It does not know what any of them cost, what benefit was promised in exchange, or who approved the spend. Those facts have no native home in Jira.
The Atlassian Marketplace has a mature category of portfolio and roadmap apps. They extend the same scheduling layer. Richer cross-project timelines and Gantt views. Deeper work hierarchies. Program boards. Capacity and resource planning down to the individual. Portfolio views on Jira tiers that do not include Plans at all. Teams that outgrow the native tooling, or never had it, generally find what they need in this category.
These apps are good at their job. They answer the delivery questions at portfolio scale — who is working on what, where the dependencies collide, whether the plan survives contact with actual capacity. If your problem is that the roadmap no longer fits on one screen, this category solves it.
What they share with native Plans is the frame. They are delivery instruments. The unit of interest is a piece of work and its dates, not an investment and its case.
Portfolio management exists because someone is paying for the portfolio, and the people paying ask different questions from the people delivering.
Delivery tooling answers one question well. Are we shipping? Boards, timelines, velocity charts and burndowns all serve that question, and between native Jira and the roadmap apps it is answered thoroughly.
The funding side has three questions, and none of them is that one.
A project can be green on every delivery measure and still be a bad investment. The team is shipping, the sprints are healthy, the timeline holds, and the business case that justified the spend eroded two quarters ago. That possibility is why portfolio governance exists as a discipline separate from delivery management.
In most organisations running Jira, the answers to those three questions live outside Jira. The business case is a slide deck from the approval meeting. The approval itself is an email, or a minute in a document nobody can find. Benefits were estimated once, in a spreadsheet, and never revisited. Stage gates happen in meetings whose outcomes are recorded inconsistently or not at all.
The gap runs between two kinds of record. The delivery record in Jira is immaculate — every status change, every comment, every estimate revision, timestamped and attributed. The investment record is folklore. When an auditor, a sponsor or a new CFO asks who approved this spend, on what numbers, and what changed since, someone goes digging through old decks. The roadmap apps do not keep this record because it was never their job. Neither does native Jira.
Tollgate is a Forge app built by Softwired that keeps the investment record inside Jira, alongside the delivery record.
Each initiative carries a business case with NPV, IRR and payback period, so the original justification is a live document rather than an archived deck. Work packages link directly to Jira epics, which ties the investment view to the delivery view without duplicate data entry. A risk register sits with the initiative it belongs to. A decision and change log records approvals, gate outcomes and scope changes with a full audit trail, so the answer to who approved what, when, on what numbers is a lookup rather than an excavation. Investment Health and Portfolio Health dashboards summarise all of it as RAG cards, which gives a steering committee something to steer with.
Tollgate works alongside roadmap tools. Keep Plans or your roadmap app for schedule, dependencies and capacity. Tollgate holds the case, the gates, the risks and the record. The two layers answer different questions and coexist in the same Jira site.
Because it is built on Forge, Atlassian's app platform, Tollgate runs on Atlassian infrastructure and your data stays there. There are no external servers and no data egress, which shortens the security review considerably. It is priced per user through the Atlassian Marketplace, on the same bill as Jira itself.
If the investment record is the layer your portfolio is missing, view Tollgate on the Atlassian Marketplace.
Tollgate keeps the business case, the gate decisions and the payoff in one record, next to the delivery they pay for.