What about using Epics as holder of business requirements?

[Anders]

Currently we use JIRA and Confluence. Confluence for the business requirements, and JIRA where Epics links together the requirements and the user stories.

We are thinking on make it even more agile by removing the documents in Confluence, and directly have the requirements and documentation in the Epics. We also plan to add a Kanban bord for just hadling the Requirements/Epics to display the priority, status of the requirement, and so on.

What's your thoughts on this? Can you see and pro's or con's?

I'm very thankful for all input!!

[Nicolas Bourdages]

In my experience, using Epics as "large stories that may span more than one sprint" works well. Depending on the complexity of your software and the size of your development team(s), you can use components as well.

Pros:

• Easy reporting. Agile can generate reports based on Epics
• High visibility. Using the Epics panel on the left, it's clear how big your requirements are and how close they are to be completed. The issues cards themselves are clearly identified as belonging to an Epic with the colored lozenge.

Cons: 

• You'll probably want to assign a simplified workflow and screen scheme to your Epics, since all the "real" work, including estimates, will be done in the user stories (or in many cases, in the subtasks of the user stories)
• Using a separate board for your Epics seems like an extra hassle. The Epics panel in your scrum board shows these infos already. If people really want to see only Epics in a separate board, I suggest using a filter gadget on their dashboards. 

I say, give it a try. If that doesn't work, look into other plugins, like Structure.