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!


Best Practice Structuring Jira Projects and Scrum Teams

We are graduating from having one large scrum team on one project to something more structured and I wanted to get advice on the best way to utilize Jira to do this. My main goals: 

- Track velocity accurately across different scrum teams so that we can better forecast capacity

- Be able to manage clean backlogs to communicate to the business (and hopefully use velocity to predict capacity for future sprints

- Efficiently organize sprint planning so that not everyone needs to attend every sprint planning. Right now its one massive sprint planning which seems unnecessary

- I want to organize sprints by goals and topics instead of splitting the sprints by FE / BE / Mobile which is what we do now.

We have: 

- 3 main initiatives / projects 

- 2 evenly divided FE/BE Team Scrum Squads 

- 1 Mobile Team Scrum Squad


Where I am struggling is: 

- If we divide the 3 initiatives into 3 separate Jira Projects, then I essentially have 2 scrum squads that are divided across the projects. I am not sure how we logistically manage boards, planning this way. I'm also concerned about how we manage backlogs across the projects with the business if we are moving squads between projects all the time.

- I don't have enough scrum squads to divide each one into an individual Project cleanly. 

- I could create just one project for the 3 initiatives and maybe use Components to divide the tracking. However then we would need to potentially combine the backlog and prioritize across initiatives which will be a little difficult to manage with the business.


Please send me your best use cases and structures so that I can get this structured correctly. Thanks in advance! 

1 comment


Log in or Sign up to comment
Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Apr 09, 2021

Hello @Paige Green ,

Thanks for reaching out and I do not have a direct recommendation more of advice on where to look, as when it comes to best practices in agile there are a lot of varying answers as the design is to allow for more fluid and agile approaches to make things work based on different approaches, but there are a few concrete concepts that can help here.  I recommend checking out the articles highlighted in:

Addressing the concept of the team breakdown is that Agile best practices call for a team to have their own, single, backlog and tracking board, so that the team is able to focus on their own work and track individual team metrics, such as Velocity or Cycle Time.  Basically, One rapid board = one agile team, however, you do not need to isolate a team member to a single team, and look more into cross-functional teams with a really good writeup on this with more information in "How to Build a Cross-Functional Team" , the drawback is the users that operate in multiple teams will have multiple backlogs to manage.  again thie drawback can be addressed with user-specific dashboard filtering relevant content to the individual via JQL for "assignee = currentUser()"  and filtering by other constraints like the components you mentioned and sorting on something like priority or rank.

But do take note from that article:

The truth is that cross-functional teams can go either way. When they work well, these teams speed innovation and enhance members' skills and job satisfaction.

And when they don't? There's nothing like wasting a bunch of time and energy without getting results (unless increased stress and animosity is what you’re seeking).

So I believe the key question to take away is "would your teams work better in a centralized location  (single board) or with independent locations per task (separated boards)"

And there is a few really good conversations in the following threads that go into these concepts even more that I recommend checking out:

Then there is another discussion on here, particularly highlighting this comment as it really sums it up for the how-to approach:

 Ian Mitchell
 02:52 pm October 22, 2014

> best to tackle the issue of adopting a scrum approach
> for multiple projects simultaneously, using the same development team? 

Scrum has a product rather than a project focus. A team must be able to commit to Sprint Goals for the delivery of successive product increments. Team members can only work on multiple products simultaneously if their ability to make these commitments will not be compromised.

Sometimes it is possible to combine the work for multiple products into a single product backlog. This requires the existence of an aggregate product which can be represented by a single Product Owner. The problem of managing any competing interests can then be reduced to a matter of prioritization.

If the products are indeed separate, then you might consider interleaving sprints so that each product is worked on in rotation. The sprints would have to be short enough to ensure that each product is worked on at least once per month and a potentially shippable increment is delivered.

 Hope this info guides you on the decisions.


AUG Leaders

Atlassian Community Events