4 answers
1 accepted
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.
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.
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.
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.
- 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.
- 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.
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
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.
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.