Thanks to everyone who joined the Visualize work across teams session on Plans in Jira on 27 October. We covered the basics, and your questions led us to consider some of the more challenging aspects of cross-team planning:
What happens when several teams, different ways of working, and shared people all need to fit into one plan?
I said I’d go away and check a few things. Here are the answers, along with a couple of clarifications. There are quite a few menus in Plans, so I’ve included the settings worth checking rather than just saying “yes, you can do that”.
This post is about Jira Cloud. The advanced planning and capacity features referenced here are available with Premium and Enterprise. Older documentation still uses “Advanced Roadmaps”, “projects” and “issues”; you’ll also see “Plans”, “spaces” and “work items”.
Can one plan bring together lots of teams and boards?
Yes. You don’t need a separate plan for every board. A useful starting point is to bring the relevant work into one plan, then use different views for different conversations: delivery detail for the teams, dependencies for coordination, and higher-level work for leadership.
For capacity planning, use the teams’ boards as work sources. This is an important distinction. Adding a space or saved filter can bring in work, but those sources don’t provide capacity information. Associate each team with its board.
A board is the source of work; a team is who you’re planning that work for. Adding one doesn’t replace configuring the other.
If a sprint has an EXT. label, its board isn’t included as a work source. You can assign work to an external sprint, but you won’t get the advanced capacity tools for it until you add its board.
My suggestion for a program with lots of squads: start with two or three boards, confirm the right work and teams appear, then add the rest. It’s much easier to spot a configuration problem before you have twelve teams on screen.
Can Scrum and Kanban teams be in the same plan?
Yes, but they don’t have to use the same delivery method. I may have made this sound rather more restrictive during the session than it needed to be. You will need to make some adjustments, but it’s possible,
The important difference is how capacity is measured:
Team | How capacity works |
|---|
Scrum, using story points | Capacity is per sprint. A capacity of 30 points is for the whole sprint, not 30 points per week. |
Scrum, using hours or days | Multiply weekly capacity by the sprint length. A team with 40 hours available per week has 80 hours over a two-week sprint. |
Kanban | Capacity uses time-based estimates in fixed one-week planning iterations. |
For a mixed-team capacity setup, use hours or days as the common planning unit. Story points are only available when all the teams in the plan are Scrum teams; adding a Kanban team removes that option. Changing between story points and time-based estimation also erases unsaved estimates, so review changes first. That doesn’t mean pretending every team works the same way or inventing a conversion like “one point equals eight hours.” It means agreeing on time-based estimates for the work you want to compare in that plan.
For example, a booking team might plan in two-week sprints while an operations team has 120 hours available each week. You can discuss both teams’ contribution to the release without giving Operations artificial sprints.
What about QA or specialists shared across squads?
This was a really useful question. A team’s capacity and an individual person’s availability aren’t quite the same problem.
There is now a documented individual capacity planning feature for allocating people’s time across spaces on a site. It has a People view and a Work view, and lets you allocate hours, days, or percentages to epic-level work or higher, Atlassian projects, and entries such as leave or training. This is separate from the team-and-sprint capacity view we looked at.
The documented setup is:
- In a space’s navigation, select Add to navigation.
- Select Capacity, then add it to navigation.
- Add the people and work you want to plan.
- Allocate their time in the weekly grid.
One caveat: this currently uses a fixed 40-hour working week. It doesn't reflect custom working-day and time-tracking settings, so check that assumption before using the percentages to represent someone’s actual availability.
For shared QA, my practical recommendation would be:
- Keep a clear record of the QA work that actually needs doing.
- Split genuinely different pieces of work into separate items with owners and estimates.
- Link delivery work to QA work when there is a real dependency.
- Include the relevant work sources in the delivery plan.
- Use individual allocations to make the person’s commitments across squads visible, where that feature is available on your site.
I wouldn’t duplicate the same QA task into every squad just to make it appear on every board. You’d then have several records of the same work, potentially several estimates, and a question about which one is telling the truth. Separate tasks are useful when they represent separate effort, not duplicate bookkeeping.
As a simple allocation example, someone working a 40-hour week might spend 16 hours on Booking, 16 on Search, and 8 on support and unplanned work. That is one person’s week, not the full capacity available to each squad. This is a planning example, not a promise that team membership will automatically balance their workload.
4. Was the green bar showing completed work or allocated capacity?
This deserves a clearer answer! We had a slightly confusing combination of demo data, grouping, and filters.
The green capacity indicator is not a completion percentage. It rises as work consumes the iteration’s capacity and turns red when assigned work exceeds that capacity. Open the sprint’s capacity details to distinguish:
- total capacity
- work planned
- work completed
- the breakdown by status
- unestimated work
- scheduled work that isn’t assigned to the sprint.
If the capacity indicator shows 13 points against 30 available, don’t read that as “13 points completed”. Look at the work completed figure separately. A Done value also needs investigation.
I can clarify how the indicators work, but I can’t retrospectively prove the exact cause of every number in that generated sample plan without inspecting those work items.
If the board and plan seem to disagree, I’d check these in order:
- Am I looking at the same sprint and team?
- Which filters are active in the plan and on the board?
- Are the relevant boards included as work sources?
- Which team is assigned to each work item?
- Are estimates present, and what unit are they in?
- Is there work scheduled during the sprint that isn’t actually assigned to it?
That last point is important: work assigned to a team and scheduled during its sprint can consume capacity even without a Sprint value. Unestimated work is listed separately in the capacity details. [6][14]
5. Can I filter on a custom field?
Yes, for supported field types. I said I’d check, and the answer is more specific than a simple yes or no.
Plans support these custom-field types as filters:
Field type | Notes |
|---|
single-choice select | |
multiple-choice select | |
checkbox | |
radio button | |
label | |
Showing a field as a column doesn’t mean every field type can also be a filter.
To add a field, go to More actions next to the plan name → Plan settings → Timeline → Add fields. You need Plan administrator permissions to add fields to a plan.
The field must also be associated with the relevant space and work type. If it’s disabled for some work items, check the Applies to work items column in those settings. Changing the underlying field configuration may require an administrator. Fields from team-managed spaces are limited to work items within their own space.
6. How do dependencies work across boards and spaces?
Think of a dependency as a relationship between work items, rather than a connection between two boards.
For a travel site, the Booking team might be waiting for Search to publish a supplier availability response. Those are separate pieces of work in separate spaces, with a blocking relationship between them.
The dependency details distinguish incoming is blocked by relationships from outgoing blocks relationships, and show the dependent work item, status, assignee, and lead time. You can open these details using the dependency icon on the timeline.
For the cross-team timeline you want to discuss, bring the relevant work into the plan and check the filters before assuming a dependency is missing. The documentation I checked describes dependency details and external teams, but doesn’t establish that blanket rule for every dependency surface. I’d want to test a concrete out-of-scope example before giving a definitive answer about how it will display.
Also check the dependency configuration. With sequential dependencies, linked work in the same sprint can be flagged as off track. Concurrent scheduling has different implications. Changing the configured dependency link types is an administrator task that applies across plans on the site, so I wouldn’t change it casually during a demo.
7. Should a finish-to-start dependency automatically move the next item?
Drawing a dependency line won't produce a new schedule.
If you want Jira to propose a revised schedule, the auto-scheduler considers dates, estimates, capacity, and dependencies together. That is why it can make changes beyond the two items you were looking at. You can still schedule work without an estimate by date, but it won’t be included in capacity calculations.
I suggest trying this with a small, well-understood set of work first, ideally in a scenario. Review the proposal carefully before committing.
8. Can I compare the original plan with what we actually delivered?
There are three different things here, and I wouldn’t use the terms interchangeably:
What you want | What to use or check |
|---|
Another presentation of the current plan | A saved view: different fields, filters, colors, and grouping. |
An alternative future | A scenario: for example, different capacity, dates, or scope. |
A record of what was agreed at the start | A deliberately retained, dated baseline record. Don’t assume a saved view is one. |
Views and scenarios are planning tools, but that doesn’t create an immutable, point-in-time baseline for comparison.
A straightforward method is to agree on the baseline, then export the timeline data as a CSV and keep it with the date and assumptions. The export only contains data visible on the timeline, so check the fields, filters, and hierarchy before exporting.
For a useful comparison later, I’d retain at least:
- work item key and scope
- agreed target dates
- team
- estimate and estimation unit
- release, where relevant
- the date the baseline was agreed
- the filters and assumptions used
At review time, compare the same work item keys and record scope additions and removals separately. Decide what “actual” means as well: completed scope, completion date, and time spent are three different measures. Those are reporting recommendations, not an automatic report that Plans.
9. How do I share a leadership view without people changing the plan?
For leadership, I’d keep the detail fairly high-level: major pieces of work, target dates, progress, and dependencies that need a decision. Save that view so you don’t have to rebuild it each time.
Then check access. Plans viewer permissions provide read-only access; people also need access to the plan and the underlying spaces and boards. Your Jira administrator may need to check the permission groups, especially if someone already has broader Plans permissions.
To embed the plan in Confluence:
- Save the view changes.
- Select Share → Copy link.
- Paste the link into the Confluence page.
- Change the Smart Link to Embed.
The current Smart Link embedding process replaces the older Jira Premium Plan macro. An embed doesn’t grant access to the data; without the required permissions, it can appear empty.
For a meeting pack where the picture must stay exactly as it was, use a dated static export rather than a live embed. Label it clearly so nobody mistakes an old picture for the current plan.
A sensible place to start
If you’re trying this after the class, I’d suggest:
- Bring in two boards whose work you know.
- Check the teams and estimation settings.
- Add one real cross-team dependency.
- Open a sprint’s capacity details and make sure you can explain the numbers.
- Save one delivery view and one leadership view.
- Only then start experimenting with scenarios and auto-scheduling.
You asked about backlog planning and JPD. Here's the Jira Product Discovery learning path.
Thanks again for the questions. They were useful precisely because real teams don’t all fit neatly into the same delivery model. Try this with your own boards, and if you don’t mind sharing, let me know where the plan stops matching how your teams actually work, because those are useful examples to understand and work through.
References
