Multiple 'done' columns on board?

[J B]

Hello, on our board we have only one 'Done' column at the moment, but we like to add another. For us there is a clear distinction between 'done' and 'released'. I've tried adding a new column to the board called RELEASED, and added a status, but now the DONE column is shown blue, what indicate its not done? Both columns should be considered done for reporting e.g. 

Is this not possible? Why it is possible to have multiple 'blue'/In Progress statuses but only one Done? 

[Gabriela · Accepted solution]

The board only treats the LAST column as done. That's the whole thing here. When you added RELEASED to the right of DONE, DONE stopped being the final column, so the board no longer counts it as complete, which is why it went blue. A board has exactly one completion point, the rightmost column, which is why you can stack several In Progress columns but only one counts as done.

If you want both Done and Released to count as done on the board, put both statuses in the same last column. One column, both statuses. A column holds as many statuses as you want, so the done-vs-released distinction still lives on the cards (it's the status that differs), and the board counts both as complete because they share the final column.

If you genuinely need them as two separate columns and still showing as done in JQL, filters and dashboards, set both statuses to the Done status category (the green one), and statusCategory = Done will catch both regardless of column. The board's own grey-out and the sprint report still key on that last column, not the category. So which reporting matters most is what decides it.

[__ Jimi Wikman]

In addition to Gabriela's answer, I want to add that Release is actually a different functionality in Jira, as you have the Versions/Release functionality that connects multiple tasks to a release.

In many cases, it does not make sense to have Released as a status because it is implicit in the Done column as part of the definition of done. This is common in CI/CD setups where you build individual code additions as you build them without a formal release process.

In more formal release processes, you tend to have multiple tasks in a release branch. Since you want to mark multiple tasks, you want to have a field for that, which is where the release function comes in, as it is a standard function. This also ties into the affected version and fixed version fields for defect/incident management that are also driven by the release function.

In both cases, you would not have an additional status for Released, but rather it will be Closed or Done that is your final state of work. Release is then handled separately as a separate function.

This depends on what you are tracking and whether you are working with a transitional or operational task. Transitional tasks like Epics have no work in them, and they are just transport containers. They can have a released state, but then they would not have a closed state.

I also see that you have multiple green statuses, and one of them is duplicating the resolution function (won't fix). Unless you have removed that standard resolution, you can end up with a status closed, and resolution won't fix, and a status won't fix with resolution closed. It is usually a good idea to have a few green statuses and work with resolutions, but sometimes you want a few resolutions and use green statuses. The key is just not to mix the two :)

[J B]

Thanks both for the reply's. Currently we do not use the release functionality provided by Jira, but have our own git connections to commits/releases to main branch. I guess the committed/released git being in the same column is for now just a visual thing on the board, for Jira's perspective they mean the same thing, for us developers not. 

On top of that, there are multiple team's that work with different status (and workflow's/issue types for that matter), hence the seemingly duplicate statuses. We still need to merge them. 

[__ Jimi Wikman]

If you have not explored it yet, there are triggers in the workflow that you can use to automatically transition tasks based on pull requests and other Git-related actions.

I know some teams where the developers never touch Jira and still get everything updated through their IDE and Git alone ;)

[__ Jimi Wikman]

"On top of that, there are multiple team's that work with different status (and workflow's/issue types for that matter), hence the seemingly duplicate statuses. We still need to merge them. "

You are absolutely not alone in this. Almost every company has fragmentation of their ways of working in one way or the other. It usually is because there is no governance and/or no defined process for how to work on organization level.

I think we will see this change in the coming years, as AI heavily depends on structure, and fragmentation of processes and/or nomenclature will harm any effort to take advantage of AI.