nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

EPIC Status Vs Status

Mathieu Barbeau

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

Thanks!

Accepted answers

Alex Christensen

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

All comments

Alex Christensen

Mathieu Barbeau

Hi,

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

Alex Christensen

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.

Nick Muldoon

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.

Regards,
Nick Muldoon
Product Manager, Easy Agile

Prem Chudzinski _extensi_

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.

Mathieu Barbeau

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.

Matthias Krakovsky

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.

BR,
@Matthias Krakovsky

Lisa Förstberg_ov9lib

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
logger.setLevel(Level.ALL)
CustomField epicStatusField = customFieldManager.getCustomFieldObject(epicStatusFieldId)
OptionsManager optionsManager = ComponentAccessor.getOptionsManager()
IssueManager issueManager = ComponentAccessor.getIssueManager()
ApplicationUser user = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()
logger.info("Event triggered for Issue:" + issue)
if (issue.issueType.name != "Epic") {
logger.info("Issue is not Epic, stopping further processing")
logger.debug("\tIssue Type:" + issue.issueType.name)
return
}else {
logger.debug("Issue is epic")
}
String statusCategory = issue.status.statusCategory.primaryAlias
logger.debug(issue.status.statusCategory.properties)
logger.info("Issue Status Category:"+ statusCategory)
logger.debug("\tIssue Status:" + issue.status.name)
Map <String,String>statusToEpicMap = [// Status category: Epic status
"To Do":"To Do",
"In Progress": "In Progress",
"Done": "Done"
]
logger.info("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)
logger.info("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)
indexingService.reIndex(issue)

Dean Wheatley_hswkif

Jira Epic Status vs Status (for an Epic type) is such a bad design, and because of this, leads to unexpected behaviours like closing an epic but it still appearing in a Scrum Board because its Epic Status is not "Done" (e.g. still "To Do").

Jira should just fix this fundamentally in their solution, and not require users to implement customizations.

Dean Wheatley_hswkif

The fact that the majority of https://confluence.atlassian.com/jirasoftwareserver/working-with-epic-statuses-1014679364.html is dedicated to explaining this problem and providing instructions of how to workaround it, suggests to me that a better solution would be for Jira to introduce a breaking change to Jira to just implement it by default, and allow users to override it if they want to preserve legacy behaviour.

Abhi Singh

Absolutely agreed, 'Epic Status' is redundant and absolutely useless. I like the Atlassian is (finally) taking steps to integrate Epics into the overall hierarchy with moving to the Parent field (instead of Epics having their own Epic Link field to tie issues to). Now, it's high time they get rid of Epic Status (just like Epic Name vs Summary - gosh, who designs these things?).

Anyways, I found this automation very useful to transition 'Epic Status' to done upon the Epic's regular workflow status being marked as Done: https://community.atlassian.com/t5/Jira-Software-questions/Looking-to-automate-marking-an-quot-Epic-status-quot-quot-Done/qaq-p/1952995#U2655327

Rafa_qznmo3

they cannot fix these foundational issues because they're busy redesigning the navbar and changing the color of the status of issues (I mean, work)

I am pretty sure my company has spent more time dealing with bad jira decisions and doing work despite jira's terrible architecture than actually being productive thanks to jira.

/rant

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software