Hi admins,
What are the best practices regarding closing an epic vs. resolving one?
We have a company-managed project, wherein issues’ final status is “deployed” with resolution “done.” The options for completed epics are “resolved” or “closed.”
Hi Holly,
I would say Both? You moved it to a Closed status but then set the resolution to Done. Just like you do with tasks or stories or whatever - they move to a Done status but you also set the Resolution to Done.
"Resolved" signifies work is complete and is ready for the requestor to acknowledge. Requestor would then acknowledge completion and mark it "closed"."
I would argue that that depends on how you are using epics.
In terms of resolution (resolved vs closed) on an epic - I am not sure if that matters structurally to Jira beyond the reporting aspects. You could use those two terms to differentiate between epics which did not make it into production (resolved) vs those that were successfully deployed (closed). Or, and better, use as Bansal suggests.
I will point out that marking an epic as Done within the Backlog Epic listing, which is not the same as marking the resolution of the epic as Done (unless Atlassian fixed this and I missed it), can prevent Jira from showing that epic as an assignable epic link when linking issues to epics. This prevents your users from assigning issues to epics that are completed. That can be done by navigating as shown here:
I like these answers. At the end of the day, it is your company's workflow. Various filtration mechanisms in Jira are set by default and/or can be set to use this status as search filters for how the system outputs issues of this and other types.
Wow, I’ve always wondered about Mark as Done but never bothered to actually check the documentation on this function, thank you. Would you happen to know if there is a specific reason this isn’t handled via a final status by Jira? Is there some sort of intended flow?
I like this option, as it would help us close the loop with product and project managers.
No idea. I wonder if this functionality is actually an abandoned artifact from before the resolution functionality was incorporated. That might explain why the interface to reach it is in the backlog.
The lack of integration between the Mark As Done in the Backlog and Set Resolution: Done in the workflows could also fall under JIRA's general lack of out-of-the-box functionality about handling parent-type issuetypes (simplistic workflows that don't really do anything).
Your guess is as good as mine!
Exactly. I should have asked for best practices :-)
@Abel Linebergerdoes "Mark as Done" set the Epic Status? There's an Epic Status field, separate from the Status field. We've added post-functions to our workflows to set Epic Status based on Status.
For work tracking in Software Projects, we are focusing Epics on a time bound set of Stories or Tasks that are related at a visual management/sponsor level. This lines up well with Roadmaps and Plans. Therefore Epics are Closed/Done/Completed based on our usage and there is no need for 'Resolution'.
Our practice is, we need to ensure all the Stories in the Epic are completed (Done), and once Done, we are Closing the Epic as well if those Stories linked to Epic are satisfied. But if the Epic is much broader, like stories keep on adding, We are keeping it to In Progress.
It is a matter of taste. Generally speaking Resolved means that all works are done and Closed means that manager is happy with resolution and Epic is no longer needed.
A rule of a thumb: if you ever searched for closed epics, you need Closed. Otherwise Resolved is enough.
Here is my best practice:
I believe this is also what Atlassian teaches in their trainings. The reason is that some functionality I can't recall at the moment rely on the resolution.
I also try to use epics to represent a feature that is meant to be implemented in a given time period. This makes the roadmap feature in Jira SW Cloud Premium so much more useful.
My criteria for a feature are:
It looks like you're new here. Sign in or register to get started.
