| Issue Type | When or Who Reports the Issue | Managed by | Guidelines for Issue Reporters |
|---|
| Epic | High 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 |
|
| Story | Each 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 |
|
| Task | Only independent supporting requirements will be marked as task. No SubTask will be created under the task. | Project/Developer |
|
| SubTask | To 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 |
|
3 Comments
Chris Lott
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:
https://thedigitalbusinessanalyst.co.uk/epics-stories-themes-and-features-4637712cff5c
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".
Pantelis Monogioudis
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.
Natarajan Subramanian
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.