Jira Heroes: How Jira Admin Sue Wilson standardized the use of resolutions across projects

[#1]

At Atlassian, we take great pride in the software we ship, and even greater pride in the success our customers achieve when they use our products. #JiraHeroes is our monthly spotlight series where we ask customers to share their success stories with Jira Software. We hope that customers will find inspiration on how to overcome their own challenges by hearing how our #JiraHeroes overcame theirs.

This month, we’re featuring Sue Wilson (@swilson), who noticed that a misunderstanding of resolution and done fields were affecting reporting and took steps to configure advanced workflow functionality to standardize the resolution process across teams. 

Sue Wilson: Jira and Confluence Cloud Admin

My name is Susan (Sue) Wilson.  I live in Pennsylvania, USA.  I have almost 15 years experience administering Atlassian products on both server and cloud platforms. Currently, I am a Jira Administrator at a software company called Visual Lease. They provide lease optimization software, empowering organizations to transform their lease accounting compliance requirements into financial opportunities.  In my current role, I also administer Jira Service Management & Confluence on the Cloud platform.

How a misunderstood resolution field led to a need for consistency

The Resolution field and process have been misunderstood and challenging to resolve at multiple organizations. For example:

1. Resolution was originally configured redundantly. While auditing existing workflows, I noticed a pattern of using Resolution at each status change.  For example, when development was done, the ticket was moved to testing and a Resolution was added using a workflow post function.
   
   Then, when testing was complete and the ticket was ready for production, the Resolution was overwritten with a new value at status change.  Each change also updated the resolved date.
   
   Since each status indicated the true state of the ticket, Resolution was redundant and skewed reporting, with each ticket looking like it was Resolved (based on Jira out-of-the box logic) at the end of the development stage instead of when truly completed & closed. 
   
   
2. Inconsistent use of ‘Done'. I once had a Project Lead who felt he had enough experience and Jira ‘know-how’ to create a new workflow for his project.  Opposite the previous example, the workflow ended with a Done status that did not use the Done Category.  As a result, all Done tickets for his project over the course of ~6 months appeared to still be open and resulted in reporting that caused much management concern.

Using advanced workflow configuration to standardize resolutions across teams

To resolve (no pun intended) these administrative problems, I took the following steps:

1. All manual & automated resolution entries were removed, except at Close statuses. Where possible, the addition of a Resolution was automated through a workflow post-function.  When that was not possible, a pop-up screen was displayed to manually enter the appropriate resolution.  Thankfully, there was no requirement to back-date anything since the tasks were being closed when truly complete, and the users were made aware that the last resolve date entered was the date the task was truly closed.
   
   
2. I corrected the workflow so the final Done status was a Close status, adding a post function to fill in the Resolution so manual entry was not required by users. I then had to adjust ALL Done tickets from the implementation date of the original workflow to the present to reflect the actual date each ticket was transitioned to Done.  The ability to query the change history and use ScriptRunner to adjust dates (in bulk by date where available) helped a great deal in making this task just a little less daunting.  Reports were re-run to management’s appreciation and the Project Lead’s Project Admin rights were revoked.

Best practices for resolutions for Jira Admins

1. Use Resolution sparingly! You can create specifically worded statuses and require comments or a text field update if more context is needed for all other transitions.  It is extremely important to ensure Resolution is only used when the ticket is truly resolved….at Close.
   
   
2. Educate Project Leads on Jira. Be sure that if you give Project Leads access to administer their projects, they understand Jira configuration or at least accept guidance from Jira Administrators before making changes that can have negative impact. If they only use Project Admin privileges to add Components and Versions, great!  That saves Jira Admin a lot of work in larger instances.  Just beware they do not take liberties they should not explore!

A special tip for new Jira admins

Google is your best friend!  If you have little or no experience with Jira, Google will point you to Jira Communities that provide GREAT support.  After ~15 years as an Atlassian Admin, I still use Google and LOVE the access and support of the Atlassian Community to help me through challenges or provide confirmation of what can or cannot be done.

---

Thank you so much for sharing your insights, Sue!

Are you inspired by Sue's story? Do you have a Jira Heroes story of your own of how you’ve used Jira in a way that impacted your team? Check out our call for submissions, and let us know you’re interested in the comments! 🙌🏼

[Lars Fessler]

Great Story! I can agree with everything your say. In addition we use Status Done with a resolution (Done, won't do or something more descriptive) and in some cases a comment to state our solution to the matter. That means for us the issue was resolved in a manner we think will satisfy our customer. After that our customer can accept our solution by closing the issue or send it back to us with a comment why they do not agree.

[Dave Mathijs]

Great article Sue, the importance of (the correct use of) the Resolution field in Jira is so underestimated.

I would like to add the following KB article: Best practices on  using the "Resolution" field

[Sue Wilson]

@Lars Fessler , Thank you!  That is a great solution for interacting with the customer!  Giving them useful, meaningful Status & Resolution, they can provide informed feedback or acceptance.

[Sue Wilson]

@Dave Mathijs , Thank you!  Yes, I have seen this in every organization where I've administered an existing JIRA platform.  I love the KB article you provided!  I need to work with my current stakeholders because of their misuse of Resolution and this article provides great detail and situations where using Resolution incorrectly has negative impact!  I will most certainly use this to guide my users to best practices that will solve existing inconsistencies in function & reporting.  Thank You!

[Avinash Bhagawati _Appfire_]

Great article !

[Sue Wilson]

Thank you, @Avinash Bhagawati _Appfire_!!

[David Holman]

I've fixed a lot of Jira implementation hairballs, but this has got to be the most convoluted mess I've heard of yet. I'm sure someone will surprise me again.

[Sue Wilson]

@David Holman Resolutions have been the bane of my admin existence since almost the beginning.  They may even qualify as being more challenging than building JIRA & Confluence from scratch.  :)  I'm sure we will all hear more messy stories and be surprised many times over.

[Sven Fischer]

@swilson  Thank you for providing this advice to the community! We came across similar findings recently and it's really crucial to get proper advanced planning going. ;)

Btw we also found that moving Epics to done on an active sprint tab view, isn't closing them properly, but doing so via the backlog tab view using the respective epic sub-menu is!

[Sue Wilson]

Thank you, @Sven FischerIt seems Resolutions cause a lot of problems if the right planning is not done up front or the person building the flows does not understand the inherent process for Resolutions. It's quite the challenge to right the ship if found after long term use or the instance has many projects sharing the same workflows.

I was looking into the Epic issue you mentioned.  When using a Scrum board, I have no view of the Epic on an Active Sprint, but I can access and move it to Done from the Backlog Epic sub-menu, as you mentioned.  Not seeing it on the Active Sprint may be because we do not use the Sprint field on Epics.  In our organization, Epics can span multiple Sprints and even Releases, so we identify Sprints in the Stories & other tasks associated to the Epic, not the Epic directly. 

If I use a Kanban board, Epic can be a card on the board, but I cannot move it to Done only because the workflow does not have a Closed (Done) transition associated to it.

Not sure if I captured what you meant correctly. If you have additional information for the two scenarios, I'd love to take a look so I can either try to solve or, at minimum, warn my users what to or not to do with Epics when trying to close them.  :-)

[Rama Krishna]

Hey @swilson ,

That is a great advise.

Is it possible to share the workaround which you have used for the following statement:

I then had to adjust ALL Done tickets from the implementation date of the original workflow to the present to reflect the actual date each ticket was transitioned to Done.  The ability to query the change history and use ScriptRunner to adjust dates (in bulk by date where available) 

If you can share the process here, it really helps

[Sue Wilson]

Hi @Rama Krishna ,

Thank you.

It's been a few years, but the workaround went something like this:

1. create a JQL filter to find unresolved issues: Project = "XXXXX" AND Status changed to "Done" DURING ('yyyy/mm/dd', 'yyyy/mm/dd') AND Resolution is EMPTY.  Since I had an exact start date, I queried the 6 months in question ('Workflow Start Date', 'Current Date').  Save the filter for use in Scriptrunner.

2.  Scriptrunner:  I used 2 features:

    a.  Copy Field Value - for those tickets that were NOT updated after the date they were changed to
        Done, I was able to copy the updated date to the resolved date to adjust when they were actually
        Closed.  IF tickets were updated after the Done date, I manually updated them.  Fortunately, there
        were not many since most tickets did not require updates after marked as Done.

    b.  Bulk Fix Resolutions - using the saved filter, I updated all tickets to Resolution = Completed

Several other projects adopted this same workflow over that six month period, so I rinsed & repeated the above, changing the Project name, as appropriate.  I probably could have left out Project, but wanted to ensure I got everything updated for each, as our teams were broken down by Project/Customer at that time and each team wanted to ensure their specific tickets were corrected, as expected.  :)

I hope this helps.

[MD. MONJURUL ALAM]

Fine