Skip to end of metadata
Go to start of metadata

Hierarchy of JIRA Issues

Issue TypeWhen or Who Reports the IssueManaged byGuidelines for Issue Reporters
EpicHigh level Theme is broken down to one or more Epics by the developers of each affected project and linkages are inserted with e.g. <<depends on>> semantics to explicitly link Epics for the same theme between different projects.   Either it’s a new feature / improvement we will tag it as Epic to be captured in the requirements document.Project
StoryEach epic is broken to estimated stories by the developers and project proceeds to assignments. If any epic is run across multiple components or modules then will add multiple stories to the epic. Stories can also be broken down into SubTask.Project
TaskOnly independent supporting requirements will be marked as task. No SubTask will be created under the task.Project/Developer
SubTaskTo be created only under the Story to split the work between different owners or components. Once all the Subtask are completed then the story will be marked as done.Project / Developer


  • No labels


  1. I am not an Agile development expert, I hope a trained person like Farheen Cefalu  will add comments here. 

    The Acumos project has stated a goal of following the Agile process.  My understanding of classic Agile is that "Epic" is the highest-level, most abstract entity that gets tracked in Jira to express very high-level requirements, then epics are refined into stories (sometimes called user stories) with more detailed requirements, and so on. Ideally we'll do something similar to other Agile projects to take best advantage of people's training and experience.

    Starting with a thing called a requirement and refining that into features etc. sounds to my (old) ears like classic waterfall development.  I'm also fine with that approach, but it hasn't been the one the project has tried to follow to date.

    My searching found this as a helpful and short intro to Agile terms:

    I've found the team struggles TODAY with creating issues to track requests for new development. Choosing among Epic, Story, Improvement and New Feature issue types already is baffling.  So I'm not in favor of adding more layers above them such as "requirement".

  2. Thanks - I am not sure if the inclusion of Requirements type points to a methodology as you can take any hierarchy and apply any methodology over it. The reason why Requirements are there is to facilitate 

    (1) a traceable artifact to creating and deciding on Features. 

    (2) a traceable artifact to non functional requirements of Features and Releases such as performance. This is important for some projects. 

  3. Comments Natarajan Subramanian  & Deepti Verma.

    Rather than adding a new Issue type as “Test” , we already have Issue Type “Bug” which is used by Testing Team to track testing status. Also , for traceability purpose we can always link EPIC/ Story for that Bug so that its easy to track it down.

    Adding Issue Type “ Requirement” may or may not be useful until we clearly define what exactly are we planning to describe under it. Also, not sure if its possible to add it.

    We are currently using Jira in this Order 

    New Feature/Improvement - Leads to EPICS Leads to Story Leads to Task/Sub-Task and all the defects from the testing is tracked by Bug. 

    Just a thought, we can discuss it more.