Capacity Planning blocked 1 feb

Question

Hello,

I have created a Plan based on a Software space.

In the PPM funnel i created, under "capacity" it goes from 9 February 2026 to 1 February 2027.

I want however to plan my teams until 2028 or 2029

Is it possible ?

Thanks in advance for your help,

Best regards,

Andrey - Guenov Labs · Answer

Hi Sebastien — worth separating two things here, because I think the answer you're after is a bit different from "use Plans": you're already in a Plan, so the constraint isn't the space, it's how Plans builds the capacity horizon.

Plans distinguishes three kinds of iteration on the timeline:

* Active sprint — the one currently running on the board.
* Future sprints — sprints that already exist in Jira, scheduled after the active one. Their dates come from the board; if you haven't set dates there, Plans infers them from your capacity settings.
* Projected sprints — ones Plans invents beyond the last real future sprint, using your iteration length and start date.

Your Feb 2026 → Feb 2027 window is Plans projecting forward from your last real sprint for roughly a year and then stopping. Two things extend it:

* Widen the plan's own date range. In your plan → Settings → the timeline/scheduling range. If the plan itself is scoped to ~12 months, no amount of sprint configuration will draw beyond it.
* Give it more to project from. For a Scrum team, create more future sprints on the board (or set the sprint start date + iteration length in the team's config so projection has a cadence to extrapolate). For a team without a board cadence, switching it to an iteration-based/plan-only team with an explicit iteration length usually gets you a longer projected run.

One honest caveat, and it's the reason I'd temper expectations even once the view stretches: capacity is only actually consumed against real sprints. Work auto-scheduled into projected sprints doesn't accurately consume that projected capacity. So a 2029 capacity view will render, but the numbers in it are indicative rather than something you'd commit to.

Which is a long way of agreeing with Marc's underlying point, if not his diagnosis: for a 3–4 year horizon most teams stop doing per-sprint capacity and switch to a coarser unit — quarter-level or half-year-level team allocation, tracked outside the sprint model — precisely because headcount, attrition and hiring make sprint-level capacity fiction that far out. Sprint-level capacity for ~4 quarters, coarser allocation beyond that, tends to survive contact with reality better.

Duc Thang TRAN · Answer

Hi @Sebastien Pierron

You can vote via this link

https://jira.atlassian.com/browse/JRACLOUD-99008?jql=project%20%3D%20JRACLOUD%20AND%20component%20%3D%20%22Capacity%20-%20Capacity%20view%22

Marc -Devoteam- · Answer

Hi @Sebastien Pierron

I don't think this is possible on a space, use the Plans option to lay this out.

Why would this be useful, will there be no changes in capacity, people leaving, new hires etc.

Changes on releases, product requirements etc..?