I have a platform that is using multiple microservices. Each microservice has it's own git repository and matching jira project.
I used to be able to create an Epic within an Epic which allowed me to effectively track where a change in the top level Epic would require tasks across multiple projects to be completed.
For a simplified example of our use case, assume a front end messaging application with micro services handling all the back end functionality.
An Epic for adding messaging can be created. This requires both front end and back end micro service changes. So we create stories in each project within the Epic and everything is initially fine.
If the story is to add attachments to messages things break for us because using a story we can not add tasks for the front end to show a paperclip and the backend to store the file, because this would require subtasks going across the project boundaries and this is, rightly, not allowed. Creating 2 seperate stories within the main epic is of course perfectly possible but then the context is lost when viewing the task list in the epic because we can not see links between them in that view - whereas in our old world we could see there was another Epic and then if we were interested in what that involved we could open that epic and see the requires cross projects tasks in context.
I've considered adding it as a story then linking that story to another Epic but that seems overly complicated compared to the old behaviour where I could add an Epic inside an Epic.
Does anyone have any ideas how I can group the workload as easily and neatly as I used to with nested Epics?
