Using Jira in Feature Teams (spanning multiple Jira projects)

[ksl67]

I'm looking for advice on best practices for setting up Jira for a feature team.

Some context...

We have a distributed microservice architecture where typically we have one Jira project per service. Each service has its own Bitbucket repo. Up until now, each service has been owned by a cross-functional development team. Each has their own Jira board, sprint and makes changes only to their services.

We now want to adopt a short-lived feature team. This team will implement a new feature that will cut across multiple services and hence Jira projects.

I understand that a single Jira board can pull in stories/tasks etc from multiple projects into a single view. You just need to set up the board filter appropriately. I also understand that epics can have stories from multiple Jira projects.

My main question is which project should the epic itself belong to?

E.g. we might have an epic that contains 4 stories. Each story is against a different project. Story 1 is on Project 1, Story 2 is on Project 2 etc? Should the epic be created against Project 1, 2, 3 or 4? The choice seems somewhat arbitrary.

One suggestion has been to create a separate Jira project just to house the epics that contain stories that span multiple Jira projects. It would not be linked to its own code repo and would contain only epics that span multiple projects. Any epic that contains only stories from a single Jira project would be created against that project.

I don't think this is the correct use of Jira. It doesn't scale - a new Jira project would be needed for each feature team in the future.

Any suggestions that may help?

[Mark Segall]

Hi @ksl67 - I've had a similar architecture in my past as well with a dozen plus micro-service projects that get worked on by 1 or 2 teams.  In that instance, we just created Epics specific to each micro-service.  So if you have 4 issues across 4 projects, they would still have a project-specific Epic.  Obviously in situations where the Epic work is really small it feels overkill, but from an issue structure perspective it was the cleanest option. 

If you want to group those issues from a reporting perspective, you could leverage components or if you're on Premium, create an issue type above the Epic and store those issues on a separate project and leverage Advanced Roadmaps to surface.  This is how we handled our use case.

[ksl67]

Thanks @Mark Segall .

So if you have 4 issues across 4 projects, they would still have a project-specific Epic.

If you do this, however, it means that you don't get epics that cover vertical slices through your stack. Each epic covers only one service. Does this not cause any problems for you?

if you're on Premium, create an issue type above the Epic and store those issues on a separate project

This is effectively the same as "One suggestion has been to create a separate Jira project just to house the epics that contain stories that span multiple Jira projects", is it not? As I said, I don't think this is the correct use of Jira. 

[Mark Segall]

Sorry for the delayed response as I was out for a few days...

If you do this, however, it means that you don't get epics that cover vertical slices through your stack. Each epic covers only one service. Does this not cause any problems for you?

This is effectively the same as "One suggestion has been to create a separate Jira project just to house the epics that contain stories that span multiple Jira projects", is it not? As I said, I don't think this is the correct use of Jira. 

The answer to these questions is related.  Epics have some unique functionality by project.  Once you start splitting the work across projects, you lose the Timeline feature.  So, to answer your second question first... There's a subtle difference to a separate project for Epics vs a separate project for an issue type above the Epic which is very much a common practice for what you're trying to achieve.  Having an additional level in the issue type hierarchy captured in a separate project enables you to leverage Advanced Roadmaps. This feature is designed to provide timelines spanning multiple projects with all work rolled up to that higher level issue type. This would be the most optimal way to retain visibility into the vertical slices you reference in your first question.

If you don't have JS Premium, you could try and achieve the vertical slice visibility by leveraging components.  However, there is a bit more overhead in ensuring each component is replicated to each relevant project and issue for reporting.  You could also go labels, but I would strongly discourage this as it is a largely uncontrolled mechanism for tagging vs component.