One of the most frequent questions we get asked when on a project is, "Why do I need 'Resolutions', can't we just use statuses?" The short answer is "No" and it's because they are not the same thing. I know that you all would be terribly disappointed if I just stopped here so I'm going to outline a few reasons why it's an important field and share some best practices.
Why Do I Need the "Resolution" Field?
The Resolution field provides a few important functions to issues in Jira:
- When it's set, the issue key will be displayed as a strikethrough (KEY-556), which is extremely helpful when looking at linked issues in the issue navigator or other areas where the Resolution field is not displayed.
- It's the field that Jira uses for the "Created vs. Resolved" report.
- It's what the 'system filters' and 'gadgets' use to determine if the issue is resolved, not the statuses.
- Lastly, it's the field that sets the "Resolution Date", which is a great way to know when something was completed.
For these reasons, you are doing a disservice to your organization by not using the Resolution field. Next I'm going to talk about some common mistakes that people make and how to correct them.
Common Mistake 1: The Issue's Status is the Same Thing
While you may have created a status that reflects the same intent of the Resolution field, it's not considered to be best practice. Think about having to search every status to determine all the issues that were closed. It would be tragic if you were to forget one of them and it would be difficult to standardize around them as Jira Admins can add statuses as they see fit. Not to mention, issue statuses do not have an out-of-the-box way of knowing when something enters into that status. In reality, it's much easier to think of the lifecycle of the issue when it comes to issue statuses. If the issue is at the end of it's lifecycle, choose a status name that reflects that no more work is going to be done (I have a preference for the word "Closed" as it's neutral in meaning and conveys we're not going to be doing anything more to the issue). The Resolution field can then be used to differentiate why the issue is closed. This gives the resolution a purpose and helps people use the resolution correctly, giving the benefits described above.
Common Mistake 2: I Don't Want to Enter a Resolution
A conversation that starts like this is usually because the client doesn't care about defining the reason why an issue is closed, or they have a bunch of resolutions in the system because of poor decisions made by Jira Admins. There is one main question that needs to be asked to decide what needs to be done - "Do you always want the resolution to be the same when transitioning to this status?" If the answer is "yes", use a post function to set the Resolution to a single resolution. This will achieve the goal of setting the resolution without asking the user. If the answer is "no", then you may want to limit the available resolutions to the user. You can do one of two things:
- Delete some of the resolutions in the system.
- Limit the options available on the transition by using a workflow property.
If you decide to delete resolutions, you will be changing data for issues that have that resolution. This means you are impacting the Jira instance and may want to warn everyone before making the change. Jira won't allow you to make the change without giving a new value for the issues impacted by deleting the resolution. However, if you decide to use the workflow property, understand that this is on a workflow-by-workflow basis and will need to be instituted anywhere the change is needed. Additional information on workflow properties can be found here.
Common Mistake 3: The Dreaded "Unresolved" Resolution
I can't tell you how many times I've seen this and cringed. Here is the issue with adding an "Unresolved" resolution (other than being an oxymoron) when an issue is created, the Resolution is null, displaying "Unresolved" as the text on the ticket. What typically happens is someone will place the Resolution field on a Create or Edit screen. The Resolution field is always required when presented on a screen and since there isn't a resolution at this point, the user is forced to make a selection that doesn't apply. To fix this, a Jira Administrator will go in and create an "Unresolved" option to match the text displayed on the issue when no option has been selected. This is not the correct solution to this problem. This actually causes all sorts of data integrity issues and should be corrected immediately. Check out this Atlassian knowledge base article on ways to identify and correct this problem.
How to Use Jira More Effectively
Jira is a big complex tool that can be used in many different ways. This is just one seemingly important aspect that really can change the expected behavior of the application. We Praecipians have seen a lot of "interesting" uses of the tools and have helped guide many clients on how to use the tool to support their processes. If you are struggling with how to best use Jira for your organization, reach out! Praecipio Consulting offers Process Assessments that focus on your processes and your environment to ensure you are getting the most out of your Atlassian tools.