Best Practice Structuring Jira Projects and Scrum Teams

Paige Green March 29, 2021

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

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.
April 9, 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 scrum.org here, particularly highlighting this comment as it really sums it up for the how-to approach:

 Ian Mitchell
 02:52 pm October 22, 2014

> ...how 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.

Regards,
Earl

TAGS
AUG Leaders

Atlassian Community Events