Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

×
Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Should epics be closed or resolved?

Edited

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

8 answers

2 accepted

Suggest an answer

Log in or Sign up to answer

I would argue that that depends on how you are using epics.  

  1. Are epics surviving feature sets that are regularly updated?  
  2. Are epics specific instances of feature changes that, once completed, become part of the project record but if that feature requires additional changes outside the scope of the current instance a new epic will be created for that related work?

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:


snip.png

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?

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!

Kelly Arrey
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 25, 2021

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

Like # people like this

No, I believe resolution is older. Most of the screens currently considered mainline Jira functionality like kanban boards and the agile backlog actually stem from a time when they were part of a plug-in called greenhopper, back when dashboards were the primary interface. So probably this is just a rudimentary function. Still, watching out for this thread, really interested in what useful flows people found for this :)

Like Emma JL Rush likes this

Abel, it was the multiple ways of marking an epic as done that sent me down this path. I'm glad to see others are puzzled by that setup.

To answer your question, they are specific instances of feature changes, with a couple of exceptions. We started this Jira instance at the same time as the project, and are moving into maintain/improve mode.

I agree that Bansal's suggestion is a good use.

Like # people like this
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 25, 2021

Hi @Kelly Arrey 

The "Mark as Done' sets the Epic Status, which then also allows the epics to vanish from drop-down lists...rather than cluttering them up.

We use an automation rule to set it, similar to what you are doing with the workflow post-function on transition.

Kind regards,
Bill

Like # people like this
3 votes
Answer accepted

"Resolved" signifies work is complete and is ready for the requestor to acknowledge. Requestor would then acknowledge completion and mark it "closed"."

I like this option, as it would help us close the loop with product and project managers.

Here is my best practice:

  • I try to minimize the number of states in a workflow, epecially in the "done" status category - ideally to one, e.g. "done". This status means that the issue (including epsics) will not be worked on anymore.
  • I use resolutions to differentiate why an issue arrived in the end state, e.g. implemented, not relevant anymore, ...
  • Therefore I set the workflow to require a resolution whe transitioning to a done status.

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:

  • a set of functionality that belongs together from a business / user perspective
  • provides value when deployed to production
  • will be releases together
0 votes
Sergei Gridnevskii
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 25, 2021

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.

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.

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

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.

Exactly. I should have asked for best practices :-)

0 votes
John Funk
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Oct 25, 2021

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. 

TAGS
AUG Leaders

Atlassian Community Events