Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Capacity Planning blocked 1 feb

Sebastien Pierron
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
August 14, 2026

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, 

Screenshot 2026-08-14 101641.png

3 answers

3 votes
Marc -Devoteam-
Community Champion
August 14, 2026

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..?

 

0 votes
Andrey - Guenov Labs
Atlassian Partner
August 16, 2026

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:

  1. 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.
  2. 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.

0 votes
Duc Thang TRAN
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
August 14, 2026

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events