My understand is that one of the main way to use epics is to group related user stories within a particular release. In this usage, the epics should complete as the development for the release progresses, and an epic can be closed once the stories in it are all complete.
However, what do you do for a situation where you have a bunch of user stories related by an epic, but only some of them are targeted for the release in development, and some for a future release?
One example might be a "technical debt" epic. There are always technical debt items, but you only want to target some of them for the current release in development. Or perhaps a feature that has a minimal implementation targeted for the current release, and complete implementation for the next release. This second example isn't so good, since lends itself more to a distinct descriptions. But there are other cases like technical debt where you have more miscellaneous items, only some of which are targeted for the current release, but you still may want a larger umbrella to group them all together in some way (for example at planning time when you want to see all of them to figure out which ones to target for the next release).
Usually epics contains stories that might take more than one sprint to complete. So I think it is ok to use one instead of multiple. For reporting you can always use your fixversions and/or sprints. If you use Advanced Roadmaps then you can create another level called "Feature" or "Anything you like" above the default Epic > Stories > Sub-tasks
Ravi
To clarify, the case I have questions about concerns groups of user stories that could span multiple fixversions. I'm not worried about the multiple sprints case.
I'm not so familiar with Roadmaps, but it sounds like that could be useful. Is use of roadmaps something that has to be done when a project is first set up, or can it be slipstreamed into a setup in Jira that is already ongoing?
Thanks, Jerry
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You can always start using it later on. It will pick up the information that you already have on the issues and display it on a timeline and will also help you in scheduling the work. It has lot of features. You can read about it here.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So it sounds like one might use a roadmap level called, say, "Long Term" above epic. And then for technical debt stories for fixversion V2, would using a"V2 Technical Debt" epic and a "Long Term" property set to "Technical Debt" make sense?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I would rather not connect the *name* of the epic to the fix version. That's what the fix version field is for, if you put it in the name as well, you have redundant information. If you need to group your debt items, I think the best is to have a separate arbitrary name, like 1, 2, 3, or A, B, C. You can then later decide that the "Tech Debt A" package is going to fix version 32, and if things don't go the way you intended you can push it to fix version 33 without changing the name.
The same goes for splitting functionality into levels, "Feature Awesome stage 1", then "Feature Awesome stage 2". I came here to find good naming convention for "stage".
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.