nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Team crossover on Projects and how to handle it

Nick Gibbs

Hi all,

I'm looking for insights into how to best set up our organisations Jira environment, allowing our smallish team to manage a large product. Currently, each of our 4 teams is using Jira in a slightly different way, although we're all following an Agile framework and sprint cadence.

A bit about us:
- Approx 20 users (using Jira) spread across 4 teams: UX/Research, 2xDev teams, QA.
- One Dev team works on the core product, and the other on Integrations/peripheral products.
- Product manager UX/Research team start major initiatives and hand them over to a Developer team to complete.

Our biggest issue is that when a project requires work from multiple teams, we're doubling up or missing tasks altogether, or there are scheduling issues due to not having visibility between teams. As the Product Manager (and defacto Project Manager) I'm spending hours each week trying to work out what's going on.

I'm wondering whether our best plan of attack is to start setting up a separate Project for each 'real life' project and use filters to distribute tasks to each team for their sprint planning.

Alternatively, does it make more sense to keep all 'real life' projects on the one Jira Project, for the sake of Roadmaps?

Also worth mentioning, we're on Jira Premium so can use the Advanced Roadmaps if that helps provide a better view.

Thanks in advance!
Nick

Accepted answers

Dave

Hi Nick,

This is a great question, thanks for asking. I'd definitely recommend using Advanced Roadmaps (but then I would say that as I'm on the Advanced Roadmaps team) as it sounds like it would be a great asset to you.

However, before you read any further it's definitely worth mentioning that at the moment Advanced Roadmaps only supports Next-Gen projects. So if you're using Next-Gen projects this might not be an option for you unless you want to switch to Classic projects.

Since you're already following a scrum style agile process with sprints I'm going to assume that each team has either it's own board or project?

You could work from a single project and create a board for each team using a JQL filter that matches issues on the board assigned to a team (this is how we develop Advanced Roadmaps, we have 4 teams working from a single project each with their own board).

However if each team wants to use different workflows then it might be better to have separate projects however, I'd still recommend creating teams and assigning issues to them as this will help you to leverage the capacity management features in Advanced Roadmaps.

So I would create the 4 teams and make sure that they are shared (you can either create a team in a plan and then share it, or create a shared team from the "View all shared teams" page (accessed from the "Plans" menu).

Sharing a team means that it will show up on the issue details fields - one tip here is to make sure you configure your issue details screens to that the Team field is shown.

If your teams are working from multiple projects then you could use Jira automation (which also comes with Jira Premium) to automatically assign a team for each issue created in the project - but it is important to make sure that issues are assigned to team.

Also, if you are working from multiple projects then you could create another project that overarches all the others and then create a new hierarchy level above Epic (usually called an Initiative) and then just use that overarching project to manage the initiatives.

When you create a new plan you can import all the issue sources (ideally boards in order to see sprints on the roadmap and see the sprint capacity).

The additional hierarchy level (or levels) will help you ladder up all the story level issues to the overarching objectives and help you understand the work that is going on. The Dependency Report feature will also help you to understand the dependencies between teams.

I'm very happy to dig into any of the above in more detail if needed.

Regards,
Dave

All comments

Dave

Hi Nick,

Since you're already following a scrum style agile process with sprints I'm going to assume that each team has either it's own board or project?

Sharing a team means that it will show up on the issue details fields - one tip here is to make sure you configure your issue details screens to that the Team field is shown.

When you create a new plan you can import all the issue sources (ideally boards in order to see sprints on the roadmap and see the sprint capacity).

I'm very happy to dig into any of the above in more detail if needed.

Regards,
Dave

Nick Gibbs

Thanks, Dave, for your quick and detailed answer!
I really like what I see of the Advanced Roadmaps so far, even with limited detail in our test plan.

Re: "Also, if you are working from multiple projects, then you could create another project that overarches all the others and then create a new hierarchy level above Epic (usually called an Initiative) and then just use that overarching project to manage the initiatives."

Do you have any further information on this? I've read up on adding Initiatives but am not sure how it would work in the context of an overarching project. It sounds like it may do the trick, though.

It also sounds like this would help with the Gantt view, e.g. displaying each project as if it were an epic? Though I may be way off here...

Dave

No worries @Nick Gibbs ...

The best example I can think of for how we set up an overarching project was where we already had separate projects for various Server products (Jira, Confluence, BitBucket, etc) - in some cases multiple projects relating to different parts of the same project.

Where there was overarching work - something like GDPR compliance is a good example - we wanted an issue that spanned all those projects. Rather than picking a specific project to create that initiative in, we actually created a new Jira project just for the purpose of containing the overarching work. So in this "Server Products" project we created an Initiative issue type that we would create an issue called "GDPR compliance" and make that the parent of all the relevant Epics across multiple projects.

This meant that the overarching GDPR issue didn't belong to a specific project. Because you need to associate issue types with specific projects we reserved that "Initiative" issue type with that "Server Products" project (so that it wasn't possible to create initiatives in the product specific projects).

This approach works really well because you can create plans that pull in the work for a specific product and the overarching project without pulling in all the other project issues. So a BitBucket plan would contain the GDPR initiative and the epics related to BitBucket GDPR compliance but not issues relating to GDPR compliance in Confluence.

So in your case you might have a bunch of initiative relating to specific integrations that have child Epics across multiple projects (relating to both product development and integrations) - but you can create a plan that captures everything and track and see the progress of all the work within it (even if that work in multiple plans and on multiple boards) in a single place.

Given the current scale of your organisation an approach like this might be overkill. But if each team wants their own project in order to manage their own workflows then this might be something to adopt even at this early stage.

Regards,

Dave

Dave Rosenlund _Trundl_

Hi, @Nick Gibbs. Without taking anything away from the great advice Dave has already given you, I would just point out that Advanced Roadmaps is one of a number of options you may wish to consider for your use case.

And, I would suggest you consider the following question (it's rhetorical):

Should you form your processes around your cross-team management solution or would you be better off choosing a solution that adapts to the way you'd like to do things?

IMO, there's no "right" answer to this question. In my experience, it varies depending on the needs of the organization as well as its appetite (or lack thereof) for embracing change to maximize the benefit of a particular product.

You may want to have a look at some of the alternative solutions available in the Atlassian Marketplace and choose the one that best fits your needs (and budget).

Note: For Advanced Roadmaps, you'd have to upgrade to Jira Software Premium or Enterprise (or, maybe you are already there and it really comes down to adapting your processes to the solution vs. finding a solution that adapts to your needs).

Anyway, you can use this search (or others with different keywords) on the marketplace to see some of the alternatives you may wish to consider:

https://marketplace.atlassian.com/search?product=jira&query=multiple%20teams

Generally speaking, when scanning the results the number of installations + customer ratings is a good indicator of what's working well for folks -- but don't rule out the newer innovators completely -- they may have the best product for your particular needs or the better price.

Full disclosure: My company created one of the solutions for managing multiple projects across multiple teams (i.e., it will come up in that search result): Structure & Structure.Gantt -- and they work with Next Gen and/or Classic projects.

Good luck!

-dave [ALM Works]

Dave

Yep, that's totally fair @Dave Rosenlund _Trundl_ ... there are lots of other options that can be considered.

In this case the reason I honed in on Advanced Roadmaps was because @Nick Gibbs mentioned that he's already on Jira Premium so it's something already available to him to try. Having said that, if Advanced Roadmaps doesn't meet the needs then there are definitely other options that can be explored as you've suggested.

Regards,

Dave

Nick Gibbs

Thanks again @Dave

I've had a play around with some of your suggestions and tweaked my initial setup to see what works, and I think I've got it right now. Fortunately, it wasn't too far off, so the changes were manageable.

We're going to use the Advanced Roadmap to give our leadership team the high-level view, and some minor tweaks and a few extra boards will ensure that everyone gets exactly what they need for their sprint planning and short term planning.

Cheers, Nick

Nick Gibbs

Thanks @Dave Rosenlund _Trundl_ ,

Re: Should you form your processes around your cross-team management solution or would you be better off choosing a solution that adapts to the way you'd like to do things?

This is a great question, though one that we would struggle to answer... We've grown so quickly that we're still trying to work out exactly what 'works' for our teams, but we do know for certain that we need to get as much commonality as possible and go from there.

It's great to know that there are so many options in the marketplace, and I'm sure we'll start adding on as we find problems to solve!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

atl-gruland