What are the best practices with Epics for the following situation?

Question

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?

* Create two different epics with similar names, perhaps with the release names in them?
* Use the same epic for both - but then you cannot complete the epic for the first release, so metrics not so useful
* something else

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).

Gauthier OSTERVALL · Answer

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".

Jerry Rubinow · Answer

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?

Ravi Sagar _Sparxsys_ · Answer

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.