2

We are trying to organize our epics in a better way. In the past, the epics remained indefinitely open on Jira. Every production support/bug ticket will be added to the exsiting epic. However, since we use epics to track our roadmap (basically we have plugin that shows the epics timeline and what is active right now. It is very useful to give a big picture, since we have many epics), the indefinitely open epics render this roadmap useless.

We decided to close the epic, once all issues in that epic are closed. The problem now is, where to place production bugs/support tickets if the relevant epic is closed? If we add them to their respective epic, we will be back to keep th epic always open, which we do not want. If we do not assign them under any epic, it will be hard to track the support effort that resulted from certain epics.

Anyone faced such a problem?

6

Outside of the Jira context, an Epic represents some kind of deliverable business value. An Epic is usually made up of good Stories, the full value is realized to the client and users after all of the stories are completed and delivered. Not all Stories need to be part of an Epic. I would also say that other types of backlog items, such as items that represent technical debt or bugs, would not be part of an Epic.

I tend to use Epics to represent work that spans multiple iterations, although I can also see value in grouping related Stories per the definition of an Epic. It's also tied to a release - although in most cases, the stories could be released independently, I tend to release an Epic into production environments at once while deploying work into test and demonstration environments far more regularly. The Epic makes the work visible as it progresses through states. For example, states include Open, In Progress, Review, Test, Released. Stories move from Open through Released to mean that they are in the Epic's test/demo environment and have been coded, code reviewed, and tested. The Epic does the same, but enters Review when it's being merged into the main development branch and Test as final regression testing is happening, and finally Released to indicate all of its stories are live.

I would look at why you are continuously adding new bugs and stories to Epics. It seems like you're trying to use the Jira Epic as a Release or Tag, both of which also exist in Jira. Instead of trying to track maintenance and support effort by Epic, track it by things like component or assigned to a particular release. If you need to, Root Cause Analysis techniques can be applied to trace future work back to particular epics and you can again use tags or maybe some kind of custom fields to link support work back to the work that caused it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.