The goal of any good team or worker is to move their work to completion. Sometimes that's through Sprints in the Scrum world, or maybe the Continuous Improvement/Continuous Delivery (CI/CD) of Kanban. Or maybe even good old-fashioned waterfall.
Regardless, the goal is to get work done. And the goal any good task management/project management tool should be to track and visualize that work. So, what does that look like in the Jira world?
Definitions Matter
First, let's talk about Statuses - those steps in your workflow and columns on your boards that display your progress through the work cycle. Statuses in Jira are placed in one of three categories, To Do, In Progress, or Done. You can give the Status any name you like, but it must fit into one of those three categories.
Okay, let's say you have all of your Statuses created, and the workflow is finished, ending with one or more Done type status categories. Surely, moving an issue to the Done status will record it as truly Resolved or Completed, right? Well, not so fast.
Why is it not resolved?
In many instances, the issue is still not Resolved or Completed. Why? Here's the simple answers. First, to be "Resolved" there must be a value in the Resolution field for the Issue. Resolutions are determined by your organization and can have different values - Done, Fixed, Completed, Won't Do, Won't Fix, Canceled, etc. Jira gives you the flexibility to use the language you want and what your team/organization is used to.
How is the Resolution determined then? One way is to add a Post Function to the Transition to the Done category status. You might even have multiple Done category statuses in your workflow. But one of them needs to set a Resolution.
To set the Resolution in your workflow:
- Add a Post Function (or a Rule in Team-managed project workflows) to your transition to a Done category status. Note that this would include statuses like Canceled or Aborted.
- Use the Update Issue Field post function.
- Select the Resolution field. Then select the value for what the Resolution will become.
- Add the Post Function and Publish the workflow.
A second way is to set the same Resolution field using an Automation Rule. This is typically done when you are auto-transitioning an issue to Done for some reason.
Finally, you can add a screen to your Transition so the user moving the issue to a Done category status can select the Resolution on the fly. Do do this:
- Create a new screen.
- Add the Resolution field to the screen.
- Add the Screen to the Transition using the Edit function on the Transition.
- Note: Do not add the screen to any screen scheme.
How do I know if it is Resolved?
You will know if the issue is resolved, i.e. that the Resolution field has a value, because the issue key will not have a strikethrough and will look something like: ABC-123.
Sometimes you will see that for an issue that is not in a Done category status. Why? The most likely reason is because the issue was moved to Done at some point and then moved out of Done or "reopened". If you allow that in your workflow, but sure to add a Post Function to the reopen transition to clear the Resolution field.
What About Sprints?
You say, "I have done all of that, and still I get a message that all issues in my Sprint are not completed". Sprints and Scrum boards behave a little differently. Jira implements a rule with the Scrum boards that issues must be in the far right or list column of the Scrum board to be considered Completed for the Sprint.
That is true regardless of where your Resolution is getting set (meaning regardless of which status). This is true of Sub-tasks as well. If your Story or Task is "Resolved" but not "Completed", but sure the status is mapped to the last column of the Scrum board and that all Sub-tasks/Children are also Completed and in the last column of the board.
Feedback
What have I missed? What questions do you have? Put them in the Comments below and let's have a discussion!
3 comments