Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,296,431
Community Members
 
Community Events
165
Community Groups

How to raise work across other Jira teams

Hi. We've around 12 teams in our Jira instance, each defined as a 'Project' and reflecting a technology area (e.g. middleware, infrastructure, databases, portals etc). Often a team will receive a request which needs another teams' involvement to deliver the overall capability (we refer to this as a primary team raising a request on a secondary team(s)) - for example, one requirement might need front-end, middleware and back-end involvement (3 teams). Our current approach is that we have the primary team raise an epic directly on the secondary teams' backlog. However, this means that everyone needs write access to all teams' backlogs - which is leading to out-of-control backlogs which the BA/PO have no control over (they're getting full of noise / badly defined requirements etc).

To counter this, we're considering hardening the entry to the backlogs by making the BA/PO the gatekeepers for their own backlogs, and have all requests come indirectly via them for consideration. Given we're still largely remote, we could rely on email or Teams calls etc to handle this communication, or we could do something in Jira to cover this communication; a bit like a work request 'exchange' - in which a team raises a new issue (we're thinking of using type 'Service Request') citing the source (Team A) and destination team (Team B) plus details of the work required. All receiving teams would get a board filtered on work destined for them. So Team B would then review those inbound requests and add to their backlog themselves accordingly as they see fit, and transition the request to 'Done' as feedback to Team A that it's been actioned. I've configured this and it works fine, but it's another board for teams to manage and I'm wondering if there's a simpler alternative.

Does anyone have any comments for/against this approach - or are there any other suggestions for how we might do this? I guess an obvious answer is to operate in full-stack teams thereby avoiding this need altogether - but that's a huge upheaval which I'm trying to avoid for now.

0 comments

Comment

Log in or Sign up to comment
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you