Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Setting up plan for multiple projects


I am just starting to get into Portfolio so we can better manage our resourcing across multiple projects.

The way we currently do things is that each client project we are working on has its own Jira Project with a Kanban board where tasks are added into the back log then selected for development. During this phase they are grouped to epics and release versions as required, people are assigned and we currently leverage the due date field.

As I am fairly new to Portfolio, I would like to add all our currently working projects to a Project Delivery Plan, I am just trying to work out if its best to create a single team, as most of the team work across all the client projects, or create project specific teams?

Just wondering if someone can point me in the right direction as to what the normal approach to this might be?

1 answer

0 votes
Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jul 23, 2019

Hi Jeremy,

If you're only going to have a single plan containing all the projects, and all the users will be working across all the projects in the plan, going with one team with all the users would be the easiest way to break down the work load, with the minimal overlap on tasks.  This method would be more dependent on other scheduling factors such as dependencies and ranking to schedule the issues and would look at the team members overall availability and capacity to address the issues as they can be worked on.

However if you wanted to distinguish a more granulized effort per project to define availability of specific users you could approach this with multiple teams.  this could be used to say have user-A on team1 for project1 and team2 for project2  but only be avaliable for 10 hours a week on team1 and 30 hours a week for team2 to break up the capacity utilization for higher priority of 1 project over the other based on the teams capacity.

I would recomend using the scheduling factors doc i linked above and then doing a bit more reading to cross referance the scheduling factors against the "Capacity" and the "Team"  documentation for a better idea on how these factors can be implemented for your desired approach.

Also you can set up multiple plans with the same data sources but it is not recommended to  share resources across the plans when doing so, as covered in this Portfolio FAQ:

A plan can be used at different levels. There is no general rule to using plans – how you use plans would typically depend on how you work. You might make different plans for different programs, create a separate plan for the next quarter, or make plans for a particular set of projects. The only rule is that plans are logically separated, and should not share any data, such as resource availability. This means whenever you need to balance resources between projects and teams, put the data into one plan.

Overall there is a bit of a loose definition because it really comes down to personal preference and how you use Jira and what grouping is best suited to help define a long term road map around with the only rule being the logical seperation of data described in the FAQ.  So if you're looking into branching the data out into additional plans as well in the future i would suggest doing so now and setting up the projects into more plans and teams for the long term approach, unless you plan to maintain the larger data set grouping.   I would also recommend checking out the Blog post we have on how we use Portfolio internally for some guidance on this as well:


Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events