@Rachel Tang Thank you for this video series - it's super helpful and I've shared with my colleagues.
I do have a question about Plan Teams vs Atlassian teams, as it relates to my organisation and Capacity planning. We are scaling, and so have most people on our Product Team working on more than one project at a time - and every project works in whatever way is appropriate for them (Kanban, Scrum, Scrumban, etc.).
From my understanding, Atlassian Teams would be most useful for each Specialty (VR, BE, FE, etc.) but a Plans Team would be best for each project? Can we actually utilise the Capacity Planning in Plans - when people are working on more than one project at a time, and would be part of multiple Plan Teams? 🤔
This was a good set of videos to highlight some of the features of Jira Plans. I had not previously investigated the details of the Program and Capacity features so that was particularly educational for me. Thank you!!
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.
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.
Atlassian Team members are employees working across the company in a wide variety of roles.
February 17, 2026 edited
hey @Megan McDonnell , Apologies for missing this when you sent it.
Thanks for the kind words about the series and for sharing it with your colleagues 🙌
You’ve understood the split pretty well, and the “right” setup depends on what you want to optimise for:
1. Atlassian Teams vs Plans Teams (conceptually)
Atlassian Teams = people-group in the Atlassian platform (directory concept).
Great for: stable groups like disciplines (VR, BE, FE), chapters, or long‑lived squads.
They show up broadly across products (mentions, ownership, etc.).
Plans Teams = planning construct inside Jira Plans.
Great for: anything you want to do capacity and scheduling for on the timeline.
Common patterns:
One Plans team per delivery team/squad
One Plans team per long‑running project/program
Or a mix, depending on how you want to model your world.
So your take of “Atlassian Teams for specialties, Plans Teams for projects” is a totally valid model.
2. People on multiple projects: can Plans capacity handle this?
Yes, with an important nuance: capacity in Jira Plans today is team‑level, not per‑person allocation.
That means:
Each Plans Team has a capacity (e.g. 40 story points / sprint or X days / week).
Issues are assigned to one team, and Plans uses that team’s capacity to schedule and highlight over/under‑utilisation.
A person can absolutely be a member of multiple Plans Teams – that’s supported and common in scaling orgs.
What Plans doesn’t do (today) is automatically say “Alex is 50% on Project A team and 50% on Project B team, therefore each team gets half of Alex.” Instead, you typically:
Model the realistic capacity per team, already accounting for the fact that people are split. For example:
If a BE dev is 50/50 across two project teams, you don’t give each team a “full” BE; you reduce capacity for each team accordingly (e.g. smaller velocity or hours).
Optionally create dedicated teams per “mode of working” (e.g. a Kanban team, a Scrum team) and associate the right boards with them so Plans reflects how that work is actually run.
So yes, you can use Plans’ capacity planning in your scenario. It just works best when:
Each Plans Team capacity is set to reflect the fraction of people’s time that’s truly available to that project.
You’re comfortable thinking at team capacity level, rather than individual % allocation inside the plan.
3. How I’d model your situation practically
Given what you described (people in multiple projects; mixed Scrum/Kanban/Scrumban):
Use Atlassian Teams
For your specialty groupings: VR, BE, FE, etc.
For ownership and broader visibility across Atlassian products.
Use Plans Teams
One Plans Team per project (or per long‑lived product stream) that you need to plan/schedule.
Add people to multiple Plans Teams if they truly split their time.
Set each team’s capacity to reflect reality (e.g. if a BE dev is only ~30% available to “Project X”, dial down Project X’s team capacity rather than treating them as 100%).
That keeps your real‑world complexity (people on multiple projects, different methodologies) but still lets you get useful capacity signals out of Plans.
Feel free to reach out here or via email if you had more questions.
Kind Regards, Joe Nguyen Product Manager - Jira Plans jnguyen2@atlassian.com
41 comments