nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Capacity planning across a project portfolio?

Goran Stoyan

Hello everyone,

We’re starting to use Jira Premium Cloud Plans (advanced roadmaps) for roadmap planning across multiple teams, but we’re still figuring out the best way to model team capacity.

The idea is to use Plans to prioritize epics, schedule upcoming work, and understand how much roadmap work each team can realistically deliver.

However, our teams don’t spend 100% of their time on planned roadmap items, we usually reserve part of our capacity for bugs, support requests, and unexpected work.

The challenge is that this type of work is difficult to predict in advance. If we leave it out of the plan, Jira assumes teams have full availability for roadmap work, which makes future timelines and delivery forecasts less realistic.

What is the recommended approach for representing this reserved capacity in Jira Plans? Should we reduce team availability, create placeholder issues for maintenance work, or manage support capacity separately?

How do other teams handle capacity planning in Jira when they need to account for both roadmap delivery and ongoing operational work?

Thank you all in advance

Accepted answers

Mary from Planyway

Hi Goran,

I think your concern is valid, and I wouldn't separate bugs/support work from your team's normal Jira workflow just to make the roadmap planning work.

The issue is that Plans assumes the capacity you give it is available for the work included in the plan. Since you already know that around 20% of the team's time will go toward operational work, I would account for that at the planning level rather than trying to add placeholder bugs months in advance.

One way to handle this is to

- set the team's capacity in Plans based on the time they actually have available for roadmap work (for example, 80% capacity),

- then create separate filters for the boards connected to your Plan that exclude operational issues such as bugs,

- and use those filtered boards as the sources for your Plan.

The filtered boards don't need to become your team's 'real' boards. They are simply a cleaner input for roadmap planning.

If you're open to trying marketplace apps, you can install Planyway, which is our cross-team planning app.

Planyway lets you set custom working hours per day, either for the whole team or for individual members. By reducing the default working hours (e.g., from 8 hours to 6 hours per day), you can reserve 25% of the team's capacity for unplanned work, bugs, and support.

Снимок экрана 2026-07-24 в 08.55.33.png

You can also mark unavailable days for vacations, sick leave, or recurring reserved time for support and maintenance, and Planyway will automatically exclude them from available capacity calculations.

Also, unlike Jira Plans, which focuses on team-level planning, Planyway allows you to track capacity at the individual level across projects, plus see a visual "heat map" of your team's capacity. You can easily visualize incidents, support tickets, and maintenance tasks alongside roadmap epics on a single timeline to have the most complete picture of where your team's time is actually going.

Снимок экрана 2026-07-24 в 09.00.27.png

Hope this helps!

Happy to share more details about how Planyway handles this setup if it’s useful, and I’d be interested to hear what approach ends up working best for your teams.

Best,
Mary from Planyway.

All comments

Mary from Planyway

Hi Goran,

I think your concern is valid, and I wouldn't separate bugs/support work from your team's normal Jira workflow just to make the roadmap planning work.

One way to handle this is to

- set the team's capacity in Plans based on the time they actually have available for roadmap work (for example, 80% capacity),

- then create separate filters for the boards connected to your Plan that exclude operational issues such as bugs,

- and use those filtered boards as the sources for your Plan.

Planyway lets you set custom working hours per day, either for the whole team or for individual members. By reducing the default working hours (e.g., from 8 hours to 6 hours per day), you can reserve 25% of the team's capacity for unplanned work, bugs, and support.

Снимок экрана 2026-07-24 в 09.00.27.png

Hope this helps!

Happy to share more details about how Planyway handles this setup if it’s useful, and I’d be interested to hear what approach ends up working best for your teams.

Best,
Mary from Planyway.

Lucas_DevSamurai_

Hi @Goran Stoyan , welcome to the community.

I completely understand your concern. This comes up a lot once roadmap planning moves into Plans, because Plans assumes a team is fully available for planned work unless you tell it otherwise.

There's no single "correct" method, but here's how each of the options you mentioned actually plays out:

Reduce team capacity; the simplest and usually the best baseline. You can just keep in mind how much of availability your team actually has rather than go all out (like setting for 80% of capacity rather than 100%, which is usually unrealistic).
Create a recurring "Maintenance & Support" epic or a per-sprint story sized to your reserve. The buffer becomes explicit on the roadmap, and you can log real bugs and support work against it.

And if you ask us how our team handles capacity planning in Jira and are open to trying marketplace apps like us, I would suggest trying TimePlanner. It's our daily driver for managing capacity and balancing the team's workload.

So in TimePlanner, we can set a limit to our working capacity or working hours to avoid over-planning. Even if somehow we do, the app will highlight that day with an "Overtime signal."

More importantly, we can manage our resource planning directly where we plan our tasks if someone is on leave (or PTO) or has non-working activities like meetings. This helps us avoid overlapping and reallocate work.

Plan meetings.png

We can also keep track of who is under a heavy workload throughout the week and rebalance their capacity so our members can avoid burnout.

Balancing workload.png

Hope you find it helpful.

If you want to know more about TimePlanner or how it works in your case specifically, please feel free to ask.

Cheers.

Goran Stoyan

Hello, Mary. Thank you for the advice. A few people on our team are OOO at the moment, but once everyone's back we might give Planyway a try and see whether it fits our planning process better than what we're doing today.

Appreciate you taking the time to explain the different options

Mary from Planyway

Sounds great!
You can also book a call for a demo session with my team here: https://calendly.com/planyway-call/demo

Alexey Pavlenko _App Developer_

Hi @Goran Stoyan ,

Personally, I've never seen a team utilizing the auto-scheduler in practice. Everyone I know from major and leading companies who has tried the auto-scheduler has ended up switching to manual scheduling whether for team usage or for stakeholder alignment.

A good supplement to JIRA Plans can be an app I developed - Multi-team Scrum Metrics & Retrospectives (check the header of the bar chart for the capacity/allocation).

With it, you can:

Track:
- Data across sprints, months, quarters, half-years or years.
- Several teams (including those ones sharing the same project) at once.
- Velocity, capacity, allocation, completed story points (completed scope), planned (initial, final scopes), added and removed scopes, as well as other metrics. You can even create your own custom metrics using JQL.
- Trends and average metrics across periods.
Conduct Quantifiable retrospectives.
And many more.

3 boards/teams in the same view, 1 period selected for analysis:

3 boards/teams in the same view, all periods are clicked for average metrics and dynamics:

Best regards,
Alexey

Daria Spizheva_Reliex_

Hi @Goran Stoyan ,

Plans is genuinely good at sequencing epics and showing dependencies, but its capacity model assumes that everything consuming a team's time exists as an estimated issue inside the plan. Operational work usually doesn't, so the forecast drifts optimistic.

On the three options you listed, briefly:

1. Reducing team capacity/velocity is the cleanest of the native approaches. If your teams historically spend ~25–30% on support, plan at 70–75% of measured velocity and treat that as the roadmap capacity. The downside is that it's a single blunt number per team, it hides *what* the reserve is being spent on, and it needs manual revisiting as the mix changes.

2. Placeholder maintenance issues do make the reserve visible in the plan, but they clutter the backlog, need someone to groom them every sprint, and get confusing when real support tickets arrive alongside the placeholders.

3. Managing support entirely separately keeps the roadmap clean but you lose the single view — which is the reason you adopted Plans in the first place.

What has worked better for us is to keep Plans for the roadmap layer (epic prioritization, sequencing, dependencies) and handle capacity in a tool built for it. We created ActivityTimeline for exactly this, and the piece that solves your problem is its custom events.

You can create your own event types (Configuration → Events → Create New Timeline Event Type) based on the native Booking type — for example "Support", "Maintenance", "On-call", "Meetings". A Booking blocks a defined number of hours per day for a person, or for an entire team at once via the "Create for everyone in this Team" option. So instead of guessing at a velocity haircut, you reserve, say, 2 hours/day for support on each engineer's timeline. That capacity is genuinely gone from the workload calculation, no Jira issues are created, and your backlog stays clean. If a reserve turns out to be too large or too small for a given period, you can drag it, resize it, or split it.

A few other things that address the parts of your question:

- Involvement (capacity per person per day) can be set globally, per user, or per weekday, and Workload Schemes can be attached to Jira groups — useful if teams sit in different countries with different calendars. Vacations, sick leave and holidays are subtracted automatically, and workload redistributes itself when someone is out.

- The Team Panel lets you drop epics straight onto a team's timeline without picking an assignee, which mirrors what you're doing in Plans. An item shows either at team level or at individual level, never both, so capacity isn't double-counted.

Team panel and personal timeline.png

- Test scheduling scenarios without modifying Jira issues using Placeholders. Approving one converts it into a real Jira task, but you're not obliged to — many teams keep placeholders permanently as pure capacity-planning entities.

- The Team Utilization Pie Chart can be generated from worklogs, showing how the team's time actually split across projects. That gives you an evidence-based number for how much operational work really consumes, which you then reserve going forward. The Team Capacity Chart and Team Utilization Forecast then show week-by-week whether the remaining roadmap load fits, and Planned vs Actual shows how well your reserve matched reality so you can tighten it each quarter.

Снимок экрана 2024-08-06 в 02.34.52.png

- If a chunk of the "unexpected work" isn't ticketed at all (ad-hoc requests, meetings, mentoring), enabling "Treat Booking items as worklogs" in Timesheets Configuration makes past bookings count as logged time, so that effort shows up in reporting rather than vanishing.

Practically, I'd suggest pulling the last two or three months of actuals to get each team's real operational percentage, create a dedicated event type per category, reserve it as recurring bookings across the planning horizon, and then let Plans schedule roadmap epics against what's genuinely left. Reviewing the reserve monthly against Planned vs Actual keeps it honest.

Happy to share about ActivityTimeline if that would help.

Melika-Everview

Good question, and a really common gap! you've already spotted the core issue, which is that Plans assumes 100% availability unless you tell it otherwise.

On your three options, in order of how well they tend to work:

- Reduce team availability is usually the cleanest for forecasting. In Plans you can set a team's capacity below 100% (e.g. reserve 20-30% for bugs/support), so timelines are built on realistic throughput rather than an ideal that never happens. This is the least maintenance and keeps your roadmap the roadmap.
- Placeholder/maintenance issues work better when you want the reserved time to be visible and trackable e.g. a recurring "support & maintenance" epic per sprint that consumes story points. The downside is upkeep, and it can clutter the roadmap.
- Managing support capacity separately (a separate board/queue for operational work, kept out of the Plan) is often the most honest model when the ops work is genuinely a different flow you plan roadmap capacity at, say, 70% and let the ops queue live on its own.

Most teams I've seen land on a blend: reduce availability in Plans for the forecast, and track the actual operational work separately so you can tune that percentage over time with real data.

Which points at the harder half of your question: Plans is a planning-time model, so the reserved % is an estimate you set up front. The thing it can't do is show you, live, how much of that capacity the unplanned work is actually eating this sprint which is exactly what tells you whether your 20% reserve was right or should've been 35%.

I'm on the team at Everview, and that live side is what we built for, so I'll be direct since it's relevant here. We layer on top of Jira (Plans stays your planning tool — no rip-and-replace) and read your actual issues to show committed roadmap work vs. the unplanned bugs/support as it happens, so "do we still have capacity this sprint" is a live read rather than a plan-time assumption. It's a complement to Plans, not a replacement for it.

On the Atlassian Marketplace if it's useful to look at against your own data: Everview.Ai
But honestly start by setting availability below 100% in Plans and tracking ops work separately; that alone fixes most of the unrealistic-forecast problem.
The live layer earns its place once you want to close the loop between the reserve you planned and what actually happened.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

capacity

jira-plans