Best/worst practices question: Is having a dedicated project for Epics a terrible idea?

[Rob Horan]

For reasons I don't want to go into here, I am considering creating a solution for a customer in which they would have a dedicated project for epics.  Epics would be the only issue type allowed in this project, and creation/editing would be tightly controlled.  Users would have the ability to create stories/tasks/bugs/etc in other projects and link via Epic Link.  Are there any reasons for why this is a terrible idea?

[Tom Lister]

Hi @Rob Horan 

I would not say there are any reasons or problems for not doing that. It is common for Epics to span work by multiple teams/projects and they have to reside somewhere. We create epics in a central project and use automation to generate issues in projects owned by different regions. They all see the epic but they don’t see each other’s task progress.

[Trudy Claspill]

@Rob Horan 

This would be possible only if all the projects are Company Managed projects.

With Team Managed projects you can't make issues in one project children of Epics in a different project.

[Fabian Lim]

Hi @Rob Horan

We did create a program like that where we had epics and stories on separate projects.  As long as you have a process in place that people can follow you should be ok.

The issues we had were with reporting. For dashboards you would have pull in various projects together to determine the progress of an epic and it was a nightmare. So we ended up buying plugins such as structure and eazybi.

Now with advanced roadmaps, you may have a better way to report on them.

[Tom Lister]

Maybe try

issue IN issuesInEpics("project=EPICSPROJ”)

[Fabian Lim]

Agree on this one. Back then we didn't know about scriptrunner, but we could have used this function. :)