Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

EPIC Status Vs Status

Hi Everyone,


Well maybe my question is obvious but... I still have hard time to figure out something.


Let say I have X amount of EPICs. We start working but I some point we stop working  on EPIC A.


So, I close all the completed story as "fixed" and the others as "won't do". And so on, for EPIC A, I will close this EPIC as "won't do".


But, if I want to make this EPIC disappear from my AGILE board, do I really need to mark this EPIC as "done" (EPIC status)? That doesn't make sense :) This is not done... 



5 answers

1 accepted

2 votes
Answer accepted

What you described is the case, yes. In order for the Epic to disappear from an Agile board, you must also mark it as Done from the Agile board, even if the Epic is a Done status. Epic Status and Status are independent of one another, which is the reason for this.

I, too, don't like this - to solve it, you should be able to use post-functions in the Epic workflow to set the value of Epic Status to "Done" whenever you close the Epic, and even set Epic Status to "To Do" or "In Progress" if you re-open the Epic. You will probably need add-ons for this (I believe the JSU add-on will allow you to do this).


Thanks a lot for you answer!


Ok, well... the outcome for this is not ideal.

Indeed, in the Version Report or EPIC report, the EPIC will still appears as  "closed".

0 differentiation between an EPIC

closed "Status: fixed & Epic Status: done" or

closed "Status: won't do & Epic Status: done"

This is a very weird behavior :)

Are you using multiple statuses to consider an issue closed? I'd advise not to do that - in my opinion, you should have one closed status, then set the Resolution field to "Fixed" or "Won't Do" depending on the actual reason for why the Epic is closed. This has always been cleaner for me when creating workflows and reports for users since it simplifies the workflow a little bit.

One thing I forgot to mention - I also use the Automation for Jira add-on to "listen" for any changes made to Epic Status from the Agile board - if any are found to be marked as "Done," the issue is automatically transitioned to a closed/done status. This takes care of the scenario in which you mark an Epic as Done in the Agile board, but forget to update the status, too. :)

Like Pooja Devlal likes this

We only have one Closed status but many resolution.

My answer wasn't clear enough sorry :)


EpicA: "Status: closed, Resolution: Fixed & Epic Status: done" or

EpicB: "Status: closed, Resolution: Won't do & Epic Status: done"


Unfortunately, with this scenario, both EPICs will appear in the Version report and Epic report since those report only show the Closed status and don't do any differentiation about the resolution.


We have Scriptrunner - we might be able to add some automation on the transition.

I think our next app release will solve your issue (original question about visible epics on the Backlog list not "marked as done")

We're adding full JQL support for epic panel.

You'll simply filter out all resolved epics, or find them and mark as done.


Preview of upcoming feature.full filtering.png


Hi @Mathieu Barbeau

We use a post-function to update the value of the Epic Status field on transition. That is then used to help us calculate the cycle time of the Epics. And it is available on Cloud too.

This is detailed in Understanding the cycle time of epics in Jira.

Hope that helps.

Nick Muldoon
Product Manager, Easy Agile

As part of our plugin we display workflow statuses on the epic cards.

Its easy to find Epics in Done status and mark them as Done (Epic Status Field) directly on the backlog. 


Hi @Mathieu Barbeau,

There is even an excepted answer from 2018 but I was confronted with this issue right now and wanted to add here another comment for an available workaround.

For me the most disadvantage of this non-automated synchronization is, that there is no direct way to move a "marked as closed" epic back to the backlog sidebar. But there is a workaround to change the epic status by using the bulk change operation. If you use "find issues ..." and filter by project and epics you can choose these epics, where you want to change the epic status (for example if they were closed by accident or you have an updated roadmap and want to mark several epics as closed to hide them from the sidebar). The form for "edit issues" allows you in the next step to change the epic status.

Of course it depends on the frequency of the changes and the volume of epics you have to manage, if this workaround could be satisfying. But I suggest that on epic-level this should be applicable for refining the epics of your backlog.

@Matthias Krakovsky 

I use a Script listener to resolve this issue.

I want to base the Epic Status  Todo/ In Progress/Done  upon the Status Categories in Jira ( Todo/ In Progress/Done). Moving to Status category Done means changing Epic Status to Done etc


Trigger the listened on create, generic and resolve event.


* Once triggered this script checks if the triggering issue is an Epic
* If it´s an epic, the issues status category is retrieved and mapped against an epic status on $statusToEpicMap
* The Epic status field ($epicStatusFieldId) is then updated accordingly.
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.event.type.EventDispatchOption
import com.atlassian.jira.issue.CustomFieldManager
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.issue.IssueManager
import com.atlassian.jira.issue.MutableIssue
import com.atlassian.jira.issue.customfields.manager.OptionsManager
import com.atlassian.jira.issue.customfields.option.Option
import com.atlassian.jira.issue.fields.CustomField
import com.atlassian.jira.issue.fields.config.FieldConfig
import com.atlassian.jira.issue.history.ChangeItemBean
import com.atlassian.jira.user.ApplicationUser
import groovy.transform.Field
import org.apache.log4j.Level
import org.apache.log4j.Logger
Long epicStatusFieldId=10003 //change to your epic status custom field ID
Issue issue = event.issue

Logger logger = Logger.getLogger("cevt.common.listeners.update-epic-status")
CustomFieldManager customFieldManager = ComponentAccessor.customFieldManager
CustomField epicStatusField = customFieldManager.getCustomFieldObject(epicStatusFieldId)
OptionsManager optionsManager = ComponentAccessor.getOptionsManager()
IssueManager issueManager = ComponentAccessor.getIssueManager()
ApplicationUser user = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()"Event triggered for Issue:" + issue)
if ( != "Epic") {"Issue is not Epic, stopping further processing")
logger.debug("\tIssue Type:" +
}else {
logger.debug("Issue is epic")
String statusCategory = issue.status.statusCategory.primaryAlias
logger.debug("Issue Status Category:"+ statusCategory)
logger.debug("\tIssue Status:" +
Map <String,String>statusToEpicMap = [// Status category: Epic status
"To Do":"To Do",
"In Progress": "In Progress",
"Done": "Done"
]"Based on Status category ($statusCategory) will set Epic Status to:" + statusToEpicMap.get(statusCategory))
MutableIssue mutableIssue = issue as MutableIssue
FieldConfig fieldConfig = epicStatusField.getRelevantConfig(issue)
Option option = optionsManager.getOptions(fieldConfig).getOptionForValue(statusToEpicMap.get(statusCategory), null)"Setting field Value")
logger.debug("\tField:" + epicStatusField.toString())
logger.debug("\tValue:" + option.toString())
mutableIssue.setCustomFieldValue(epicStatusField, option)
issueManager.updateIssue(user, mutableIssue, EventDispatchOption.ISSUE_UPDATED, false)

import com.atlassian.jira.issue.index.IssueIndexingService
IssueIndexingService indexingService = ComponentAccessor.getComponent(IssueIndexingService)

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Confluence

Introducing External Collaboration for Confluence

We’re excited to introduce external collaboration for Confluence, now available in early access. It is available to preview for Confluence Cloud Premium and Enterprise customers. (If you're not on ...

199 views 0 7
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you