Best practice for adding issues to closed Epics

[Kerri Shirey]

Hello Community - We're building a next generation system and have each process captured as an Epic.  Once the Epic is developed, tested and released we expect to have enhancements requested and bugs reported.  What is the best practice to keep the integrity of the Original Completed Epic and use the same nomenclature for additional releases of the process. 

I realize it's possible to have Epic 1.0 and Epic 2.0, etc. but wanted to get other's experience as a data point for our next steps.  thank you!

[Nic Brough -Adaptavist- · Accepted solution]

The best practice is "don't"

An Epic is a collection of stories that build towards a common goal.  Once that vision has been realised, you almost certainly have something that is in production, and people are using.  

It needs no more design or people adding new stories to it, it has been delivered.

Of course, that's not to say it is entirely right, or bug free, or that people might have new ideas about how to improve it, but these are things that happen after delivery of the original Epic.  They should be tracked separately, even if you end up finding there is enough to justify a new Epic, it's not part of what you delivered before, it's new work.

[Dave Liao · Accepted solution]

Generally speaking, I recommend discrete Epics for phases of an overall project.

If you plan on closing an Epic, don’t reuse it by adding issues into it after close. Add issues to v2 or v3 versions of it.

OR have a long-lived Epic and close it when it’s totally done.