Can Jira Show a Timeline Across Multiple Projects?

Short answer: not on Free or Standard. Jira's Timeline view is available on every plan, but it shows one project at a time. Seeing work across several projects in a single planning view is a separate capability — Plans, previously called Advanced Roadmaps — and it starts at Premium. Cross-project dependency management follows the same line.

That one boundary explains a surprising number of arguments about project structure.

Why this shows up as an architecture question

The usual sequence: several teams each work in their own Jira project, someone asks for a single view of what is coming, and the timeline turns out to show only one project's work. The conclusion people reach is that the projects were structured wrong. Often they were not. The structure is fine; the plan does not include the view being asked for.

It is worth separating the two decisions before changing anything, because they have different costs. Restructuring projects is disruptive and hard to reverse. Changing plan is a procurement conversation. Teams routinely do the expensive one to avoid having the cheap one.

The workaround, and why it outlives its reason

The most common improvised fix is a central project that exists only to hold sprints or a backlog, with work from the real projects pulled into it so that one timeline has something to show. It works. It is also a permanent structural decision made to compensate for a temporary licensing one.

In the migrations we run, that pattern is consistently cheap to build and expensive to unwind two years later. Nothing dramatic goes wrong. Reports start filtering on the bundling project. Automation rules reference it. New joiners learn it as "how we do planning here", and by the time anyone revisits it, the central project has become load-bearing for things that have nothing to do with planning.

Two coherent options, instead of a pros-and-cons list

Stay on your current plan and consolidate. If the teams involved genuinely commit as one unit, one project is not merely tidier — it is the only way to get a single planning surface without upgrading. Use components or a single-select field to keep the per-area visibility you lose, and add quick filters and card colours so the board still reads clearly.

Keep the projects separate and treat the upgrade as the decision it is. If the teams really do plan independently and you need to see across them, cross-project planning is the feature you are buying. Decide that on its merits, with the licence cost visible, rather than arriving at it sideways after a restructure has already failed to solve the problem.

What we would avoid is the middle path — separate projects plus a bundling project — because it carries the coordination cost of both and the benefits of neither.

How to tell which one you are actually in

The question that settles it is not how many teams you have. It is whether they make planning decisions together. If one group prioritises across all the work, they are one planning unit and the structure should reflect that. If each area sets its own priorities and only reports upward, they are separate, and a single timeline is a reporting requirement rather than a planning one — which may be better solved with a dashboard than with a restructure.

One further signal, easy to check: if your teams merged and the projects did not, the structure is describing an organisation you no longer have. That is worth fixing regardless of plan.

Check the current plan details before you act

Plan contents change. The boundaries described here were read from Atlassian's published pricing page in August 2026, and the one that matters — single-project Timeline on the lower tiers, cross-project Plans from Premium — has been stable for some time. Confirm it against your own site and your current plan before making a structural or purchasing decision, because the point of this article is to make sure you are answering the right question, not to be the source of record for what your licence includes.