Help needed - Jira Status Workflow Question - Multiple "Done" Statuses with ReOpen in WF?

[Wendy Grapentine]

(Update at bottom of the post)

Background:  As you probably know, you can create customized statuses in Jira, however, each status you create has to be assigned to one of the three default statuses in Jira - To Do, In Progress, or Done.

My boss wants me to set up multiple "Done" Statuses with Reopen in the ticket workflow. 
My Question is - Should these be set up as Jira "Done" status category or one of the other Jira Status Categories (To Do, or In Progress)?

I'm wondering how this will affect Sprint Reports in Jira etc.

Please see attached picture.

Update:
First and foremost, thank you to everyone who responded to my post. I very much appreciate your feedback!

Before I share about what I did to fix this issue, I did want to share (for any future people seeking a similar answer) that you can set a custom status as a Jira Status Category of Done without having that status actually be resolved in Jira.  In order for the statuses to actually resolve in Jira you MUST add a post-function to the Jira Transition that goes to that status that essentially updates the Resolution Field to Done. (To clear a resolution status, you follow the same procedure to add a post function but you set the Resolution Field to None.)

Ok, even though, I could, technically leave the Resolved, QA Done, and Closed statuses as Jira Status Category Done and set them not to actually Resolve in Jira, I instead opted to change them to Jira Status Category To Do.

The distinctions that I used are a bit different than how Jira defines those three default statuses, but, I think it makes sense.  I looked at the Jira Status Categories in this way:

- Jira Status Category: "To Do" (gray color) - I defined as an active ticket that is currently not being worked on for one reason or another -- more like a transitory phase. For most tickets that would define Open, ReOpen, Backlog and To Do only, but, in my case, I believe it would include how we are using Resolved, QA Done and Closed -- these are tickets that are not "Done, Done" yet, but, are waiting to be worked on in the next step.

- Jira Status Category: "In Progress" (blue color) - I defined as an active ticket that is currently being worked on.

- Jira Status Category: "Done" (green) - I defined as a ticket at it's very end state - "Done-Done" . So the only three statuses that are in this category and actually resolve in Jira are: Done (Deployed to Production), Duplicate, and Not Fixing.

Because my boss and I do not see eye-to-eye on this issue, and because he doesn't understand what is going on "under the hood" of Jira, I decided to give him the statuses he wants, but, I would set it up on the backend my way and be done with it. 

As to how this all affects Jira reporting, I'm probably going to have to use a more granular reporting add-on like eazyBI anyway, so hopefully this won't cause any problems. (fingers crossed)

In the meantime, again, thank you all for your helpful advice!

[Wendy Grapentine · Accepted solution]

Update:
First and foremost, thank you to everyone who responded to my post. I very much appreciate your feedback!

Before I share about what I did to fix this issue, I did want to share (for any future people seeking a similar answer) that you can set a custom status as a Jira Status Category of Done without having that status actually be resolved in Jira.  In order for the statuses to actually resolve in Jira you MUST add a post-function to the Jira Transition that goes to that status that essentially updates the Resolution Field to Done. (To clear a resolution status, you follow the same procedure to add a post function but you set the Resolution Field to None.)

Ok, even though, I could, technically leave the Resolved, QA Done, and Closed statuses as Jira Status Category Done and set them not to actually Resolve in Jira, I instead opted to change them to Jira Status Category To Do.

The distinctions that I used are a bit different than how Jira defines those three default statuses, but, I think it makes sense.  I looked at the Jira Status Categories in this way:

- Jira Status Category: "To Do" (gray color) - I defined as an active ticket that is currently not being worked on for one reason or another -- more like a transitory phase. For most tickets that would define Open, ReOpen, Backlog and To Do only, but, in my case, I believe it would include how we are using Resolved, QA Done and Closed -- these are tickets that are not "Done, Done" yet, but, are waiting to be worked on in the next step.

- Jira Status Category: "In Progress" (blue color) - I defined as an active ticket that is currently being worked on.

- Jira Status Category: "Done" (green) - I defined as a ticket at it's very end state - "Done-Done" . So the only three statuses that are in this category and actually resolve in Jira are: Done (Deployed to Production), Duplicate, and Not Fixing.

Because my boss and I do not see eye-to-eye on this issue, and because he doesn't understand what is going on "under the hood" of Jira, I decided to give him the statuses he wants, but, I would set it up on the backend my way and be done with it. 

As to how this all affects Jira reporting, I'm probably going to have to use a more granular reporting add-on like eazyBI anyway, so hopefully this won't cause any problems. (fingers crossed)

In the meantime, again, thank you all for your helpful advice!

[Jim D]

Further to the above comments, you can set up your Kanban/Agile board with additional columns that make it "look" like you have multiple done statuses.  While the status category for these columns will still be In Progress, it allows you to have a logical work flow for your tickets that aligns with what your boss wants to see.

What's under the covers shouldn't really matter - it's the difference between how you visualize your work and how Jira functions.

So you can have columns and statuses created such that each status aligns with (and is even named the same as) a column on your board.

So the flow of Resolved -> QA Validation -> QA Done -> UAT -> Closed -> DevOps -> Deployed can be actual columns and statuses with "Deployed" being the only status in the Done category.

I will also mention that these interim "Done" statuses are used mainly by new Agile/Kanban teams.  They are effectively a queue for the next team to pick up.  However, each column should have a definition of Done, and when the definition is met the ticket can move into the next column.  Having a separate column to place these waiting tickets can be useful for tracking bottlenecks, but as the team matures they will become less and less relevant.

[Wendy Grapentine]

@Jim D Yes, that is essentially how I set it up.  And thank you for letting me know about the new Agile/Kanban teams thing.  I was wondering if it was coming from someplace like that.  My boss is only familiar with how they work at his previous job and does not believe me at all when I try to tell him ACTUAL Scrum practices (cross-functional teams etc.).  He wants the "hand-off" to another team idea (even though, we don't have any QA people at all at the moment.  We do have a DevOps guy though.) 

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Status category is a broad grouping of the basics for when someone not particularly embedded in your process might be looking at it.  Most humans will be asking "have you started on it yet?"  (moved from to-do to in-progress), and "is it done yet?"

The workflow diagram you've shown us is a bit broken in terms of status category.

"Done" in Jira means just "this item needs no more attention", so yes, you're right, resolved, closed, and QA done are not "done", they should be in the "in progress" status category, because they need more work.  Only "duplicate", "not fix" and "deployed" are "done".

The status category has no effect on your sprint reports.

The definition of "done" for a Scrum team is "it is in the last column of our board".

[Nic Thiele]

@Wendy Grapentine you should also be asking yourself a similar question for the "resolution" field. If an issue is placed in a "Done" category make sure that your workflow is setting the resolution field.

[Darshan Mandhane]

@Wendy Grapentine- I think, you need to make your boss understand what are statuscategories - To Do, In Progress, or Done and its usage and then you can leverage it in your workflow appropriately.

[Jaap Buitelaar]

Any of your "Intermediate Done" statuses is a "To Do" status at the same time for a next step (QA validation, UAT and DevOps).

[Nic Brough -Adaptavist-]

I mentioned "boards" at the end of my answer.

You can use boards to make things look like they are doing what you've got there, even using exactly that workflow.

Boards are a view of issues, not a container, so you could set up a series of boards that take a different view of where things are in the workflow.

[Wendy Grapentine]

@Nic Brough -Adaptavist- @Jaap Buitelaar @Nic Thiele @Darshan Mandhane - I gave an update in my original post.  Essentially, I made the three interim "done" statuses actually Jira "To Do" status category instead because it represents a still active ticket that, at the moment, is waiting to be worked on. 

[Anne Saunders]

We solved the issue you're coming up against by using different Resolution values for things that are Done. We're are also using multiple "Done" statuses.

We only use 2 ("Done" and "Closed"), and we don't use them for the purpose of reopening, but in order to automate a resolution being added, so:

• a status of "Done" is work complete and pushed to production and the resolution of "Done" gets automatically added through a workflow transition Post Function;
• a status of "Closed" means we're not working on it anymore but it never went to production, so the closing user has to select a resolution to say why (Duplicate, Opened in Error, Abandoned, etc.)  

When an issue in statusCategory "Done" needs to be reopened (rare, but it happens) we just transition it back to "To Do" with a Post Function that clears the Resolution value.

[Nic Brough -Adaptavist-]

There is a bit of a problem with doing this - it breaks a lot of the standard reporting in Jira.

If people are using the "created vs resolved" gadget, they're getting complete nonsense from it.  Most of the project reports will be misleading, and anything that relies on "assigned to me" or "open" will be useless.

Have you explained that to all your users?

In the workflow given above, the only places a resolution should be set is on the way into "Deployed", "Duplicate", and "Not to fix".

[Anne Saunders]

For us, Deployed is just status "Done" + resolution "Done" (Our issues go through QA, UAT, and Code Review statuses before they can be "Done").

For us, 'Duplicate' and 'Not to fix' are resolution values that go with "Closed." 

Reopening a "Done" issue is rare, but has happened enough that we wanted to support it. I haven't noticed anything hinky in our Created vs Resolved gadgets, but I'll be watching more closely now.

I'm interested to know what these statuses and resolutions do to "Assigned to Me" or "Open" - the assignment should be untouched, and a re-opened issue *is* Open, so I'm not sure where the fault would lie there. 

[Nic Brough -Adaptavist-]

It is mostly about the filters behind the gadgets and, well, built-in filters.  (Everything in Jira effectively runs a filter when you're working with more than one issue)

The "assigned to me", "open issues in this project" and so on is quite simple - the core filters for these are things like "assignee = currentUser and resolution is empty" and "project = XYZ and resolution is empty"

The created-vs-resolved gadget is harder to explain, as it uses two.  The first one is the filter or project you ask it to look at, of course.  That looks at all the issues and their created date, and will work absolutely fine to generate the green line.

The second one is "<your filter> and resolution-date is not empty" and it generates the red line.  If you are clearing and then setting the resolution repeatedly on an issue, then the red line is going to be inaccurate, it's not going to reflect the history.

You'll run into problems like this with almost every report you try to run, especially performance or throughput ones.  It makes your teams look incompetent from the outside because they're saying "done, oh, no, not, ok done this time, oh, um no, still made a mistake, ok, think we have it now, ummm"

[Wendy Grapentine]

Thank you @Anne Saunders - you pointed me to the right direction with the post functions.  I put an update in my original post if you are interested in seeing what I eventually did.

[Jim D]

Hi @Wendy Grapentine.  If one or more of these responses answers your question, please click the "Accept Answer" button.  If you still need help, let us know. 🙂

[Wendy Grapentine]

@Jim D I put what I did eventually in an answer and accepted that.  My answer was a conglomeration of a bit of everyone's advice here. :)

[Matt O_Brien]

Morning Wendy, 

This seems to have been covered pretty well above but will throw in my two cents. 

To my mind, looking at your flow, the only status here that should be considered 'done' is your 'deployed to production' status. The fact that you have to call it 'done-done' says a lot. 

I'd be thinking about why you are having to reopen tickets? Speaking from a personal perspective we wouldn't reopen a ticket. If the work is done it means its out the door to production. If there is an issue we will create new tickets (possibly link them to the original ticket in the release if they relate) and put them through the usual workflow to a new release or hotfix. 

I know you wanted an answer on how to create this structure but in this case I think to avoid a lot of headaches for yourself this is more about having a conversation with your boss to simplify rather than complicate your workflow. 

[Nic Brough -Adaptavist-]

You'll probably want "duplicate" and "not to fix" in "done" as well, otherwise the issues in them will never end.  They're "done" to me - you've looked at them and dealt with them!

[Wendy Grapentine]

@Matt O_Brien - my boss, unfortunately, will not listen to me.  I tried very hard to make him understand, but, what he says goes.  I wound up giving him the statuses he wanted, but, configuring Jira on the backside how I want it. (Answer in my original post)

@Nic Brough -Adaptavist-  Yes, the only statuses I put in Jira's Done Status Category was - Done (Deployed to Production), Duplicate, and Not Fixing -- using the same thought process you have - as the final stop for a ticket. 

[Arthur Harutyunyan]

Hi @Wendy Grapentine  welcome to Community !!

Basically the answer to this question mostly depends on the process you are working in. Moreover, this depends on the "Definition of Done"(DoD) you have defined in your process. 

So, yes, as @Nic Brough -Adaptavist- already mentioned, "Done" means this ticket requires no more attention, but for sure you have to define the DoD for your tickets/items. 

Based on the comments above, let me summarize the answer to your questions:

1) If the item fits the definition of done then the status should belong to "Done" statusCategory

2) Otherwise, if there is still something to be done, then you should choose either "ToDo" or "InProgress" statusCategory

I know, that it is hard to explain to boss, but you have to try :) 

[Wendy Grapentine]

@Arthur Harutyunyan - believe me that I tried, several times, to help him understand.  What I wound up doing is giving him the statuses he wants, but, setting up those three interim statuses in the category of "To Do".