+1

+1

I would appreciate it either as it would help us to align Jira to our definition of "done"

This is more or less already a feature in Board Settings > Columns, and to modify it in the way this ticket is asking for sounds like it would be an operational headache as a workflow. (Aside: the To Do column is currently grey – not blue – and the current version of the product supports multiple blue columns in the workflow between To Do and Done)

The first column in your board settings will always be Grey / To Do, and the last column will always be Green / Done. You can add multiple intermediate columns (blocked, in progress, in review, whatever) in between that are blue. 

Within any given column, you can have multiple statuses. To put multiple statuses into your Done column, you just need to drag and drop the desired statuses from the Unmapped Statuses column into the Done column (or any other column representing that stage of your workflow that corresponds to a given status).

When you're moving things across your kanban board, columns with multiple mapped statuses will give you a visual indicator of where in the column to drop the ticket to put it into a specific status within that column; by the same token, changing the status within a ticket edit screen will move it to the mapped column on the board. Things are either done, not done, or at some in-between stage, and the board supports that. Something that is To Do isn't done, and something that is Done is done – anything that falls outside of that category should be in a blue column in between. If you want to further filter the To Do or Done columns (I mostly only see value in doing it for the To Do column in aiding selection from a large number of prioritized tickets), then you can easily set up Quick Filters to filter the board to view the subset of statuses you're looking for.

+1

+1

+1 We have three different flavours of Complete:

"Closed - not a valid issue",

"Closed - no longer required",

"Closed - implemented". 

I made the stupid decision to use a Next-gen project for a large software product. Now 1600+ tickets in, various third party integrations with JIRA and loads of automation rules configured, it is not feasible to migrate to an old-gen project.

I'm using cloud and I'd love to see this. Our workflow indicates two "green" (done) columns, one for done-but-have-remarks-for-others while the other is done-and-forget (all remarks are discussed with ppl of interest). Some issues moves directly to latter, and some are first resolved into former and than moved to the latter column, usually on the end of the sprint (retro). Both of columns indicates that issues are, technically speking, done.

+1

+1

+1

+1

Yes please. Found this ticket when trying to search for how to do it. Disappointed it doesn't exist. Nextgen should allow:

• freeform columns (done!)
• a flag per column indicating whether issues with that status/column should appear in the backlog (nope, just uses first)
• a flag per column indicating whether issues with that status/column should be "done" (nope, just uses last)

+1 We track all the way through release and so we have three statuses that are all done from engineering that we'd like to have as part of burn down charts.  the other statuses are business facing statuses so we can track adoption of the new feature.

+1

+1

+1 I REALLY need this one

Any updates on this ?

This is really key to be able to have multiple 'done' columns

You really shouldn't keep a product backlog within a Sprint as Ivan above. However, I really need a "ToDo Today" as to keep me focused on what I've promised to work with during the day. To keep me on track.

In pure Scrum with self reliant teams, there are no such thing as "pending". But when working with other teams, using their own value streams, there will be :/

So my day looks like this:

• To Do (Sprint backlog)
• Today (This day backlog)
• Pending (Backlog depending on outside team resources)
• In Progress
• For Review/Test (if test fails, it can't go to done and needs to go back to To Do)
• Done

So I really need a way to keep track of work items in different states of Not started or in On Hold.

Atlassian approach to determining column category To Do | In Progress | Done is documented in this article: [Configure columns _ Jira Software Cloud _ Atlassian Support|https://support.atlassian.com/jira-software-cloud/docs/configure-columns/] and more specifically the following section (note the colours mentioned in this documentation are out of date, but the other principles still apply currently):

Each column has a blue, yellow, or green color, as shown in the screenshot above.

• The single left-most column will always be blue, representing items in 'new' state (as per our design guidelines).
• The single right-most column will always be green, representing items in a 'successful' state.
• The middle column (or columns if you add more) are always yellow, representing items in progress.

You will see these colors shown in a number of places in Jira Software, e.g. in gadgets for Jira applications.

The problem is that this approach is inconsistent with the rest of Jira application, which uses status categories that are assigned to each status to group statuses into one of To Do | In Progress | Done. This approach to grouping statuses (based on status categories) is seen throughout Jira application, and below are some examples of where you might see this:

• Release progress bar on Releases screen
• Epic progress bar on Epic details screen
• Gadgets showing issue progress

In all these cases status category is used to determine relative progress of an issue, except for Jira board columns, which totally disregards the status category of statuses contained in the column and instead assumes that 1st column is always To Do, all middle columns are In Progress and the final column is always Done, thus not allowing possibility of having multiple To Do or Done columns. This may have seemed like a reasonable assumption to someone at the time of designing board columns, but it causes problems downstream, for instance if I have a board with following columns, I'd expect the columns to categorised according to colours as shown below:

• To Do
• Selected for Development
• In Progress
• Test
• Rejected
• Done

But unfortunately, due to the current design flaw, the columns are categories as follows

• To Do
• Selected for Development
• In Progress
• Test
• Rejected
• Done

At first sight this might just seem like a semantic issue, but on further investigation we found that column status categories, are also used to render story points statistics / progress in a backlog of a scrum board and would show incorrect stats in such case. There are probably other areas (burn-down charts etc) where this has an affect.

I hope that Atlassian will take this information on board and adjust board column configuration to use contained status categories for determining column category and/or allow users to control column categorisation.

+1

We are using next-gen kanban board to track L3 issues. We have `Rejected` and `Fixed` columns to indicate the final state of an issue. But because of this limitation, we have to create a new right most column called `Done`, and manually move issues from `Rjected` and `Fixed` to the `Done` column. When we forget to do so, the list in `Rejected` and `Fixed` became super long. 

 We have other board with similar issues too. 

I agree.  This is a big limitation to us.  If we are going to not do an issue, we would like to mark it as "Done - Won't Do" or something like that.  Right now our choices are to delete and lose all of the related info or mark as Done and it inflates our burndown stats.  Please implement a solution as soon as possible.

Actually, both option would be great, Issue counts as done based on status not column (green status).

Or have a chance to choose columns color. 

Really waiting for this.

I frequently have to help customers troubleshoot their boards not acting as they expected. The probably is very often how there is a disconnect between the Status of the issue's state, and the columns specified by the board.

Counting only the far right column as "done" is just inflexible and often infuriating. Often users want multiple "done" columns: actually done, abandon (also done) to avoid accidentally picking the wrong one when dragging and dropping.

Basically, why does the column matter at all? Why not just use the states themselves to count things as done?

Agreed. This is a really annoying limitation and it impacts reporting and gadgets. Please consider making this configurable. 

+1 I'm not seeing my done statuses reflected in my burndown

I have a custom status after done as well and I can't close the sprint

Hi,

We may also want to have statuses considered as "Done" without having them displayed in the "Done" column.

For example, you may want to have a cancelled status without displaying it in the board so the user will need to go on the issue directly to cancel them. There is no way to currently precise that a status must be considered as "Done" without displaying it in the "Done" column.

I don't find a usecase for the "Todo" column, because this need is mainly because you can't close the sprint if cancelled is an unmapped status, but I have the impression that this can have added value if this suggestion is developped..... 

+1 It would provide great clarity for our development teams, to allow us to consider additional statuses as 'Done' and visually differentiate between them so that we know when work has been put in a staging environment (and in real terms all of the work is completed by the development team).  

For our workflows this would mean that the burndown charts and agile reports were useable, and work did not roll from sprint to sprint when it had been handed to the product team to demo and release.

Is there any plan on resolving this issue anytime soon? This is a very glaring limitation on Jira, and shows that they have no idea how Agile project work. I also don't appreciate the tease by allowing us to define statuses as "done". 

Someone else actually mentioned the swim lanes to us earlier, but in our case we already have a set of swim lanes that divide the work into functional areas (presentation, entity management, business logic, etc.). And while we could extend those to include a status as well, we'd end up with way too many swim lanes.

I did bypass this by combining right columns and then creating a swimlane based on JQL for status, for Closed and Released issues that seems to work out well.

But I agree with all the posters on this issue that we should be allowed to configure a column as "Done (Burndown)" as we see fit.

Our current real-world board uses multiple "to-do" and "done" columns for clarity of status. For instance, at a glance, we can see how many tasks have been completed, how many tasks have been canceled, and how many tasks have been shelved.

JIRA makes seeing this separation of status extremely difficult. Note that all tasks were started at some point, and have billable hours against them, so they can not just be removed from the board, they have meaning.

So why we are allowed multiple "in-progress" columns, but not multiple "to-do" or "done" columns? In my opinion we should be allowed to create boards that work for us, and not be prescribed a specific workflow visualization. I truly hope Atlassian can and will implement this feature in the near future.

One more vote for this. We use multiple Done states and want to have them represented by two separate columns.

+1 Agree with the above - we consider anything that is complete and tested and just waiting to be launched as "Done", but need to keep these in a separate column from the actually Launched items. Being able to move a "line" to show "tickets past this point are done" makes sense to me.

+1
We really need this feature. I don't understand why category's status of the workflow aren't map on board column, it seems so logical.

We really need to be able to define the state with which the burndown chart burns down. We can handle either if it can be defined by a choosen column or by a chosen state. But please allow something else than the rightmost column.

Any news if this will be in a future release? Seems like there is a lot of demand and it would be a great improvement when working with SCRUM.

Making the change proposed in this issue would help our team more accurately use the Sprint Health Gadget. Our team's swimlanes differentiate "open" issues from those that are "ready for development" (because an Open issue may not yet be accepted or detailed sufficiently for development work to begin). With this issue unresolved, our Sprint Health Gadget shows most of our work as In Progress at the start of the sprint, when most issues have not started development yet.

The workaround for combining these workflow statuses into one Open swimlane would allow the Sprint Health Gadget to render meaningfully, at the cost of losing the distinction within our Active Sprint view. With this issue resolved, we could avoid making this trade-off.

+1 even if I do not completely agree with Tim.

I think the suggested solution should not to add the ability to add aditionnal column.

Instead, i would like to add aditional lines on the burndown chart. In my situation i would like my burndow chart to represent 3 lines :

• a line that represent the value of stories who are not in 'In progress'
• a line that represent the value of stories who are not in 'To be tested'
• a line that represent the value of stories who are not in 'Done' (the only one available currently)

+1, this is a pretty big limitation, and most major competitors offer the feature.

Agree that this is a limitation. There should either be a way to configure it on the board for each column or just have the numbers match the Status type setting.

We really need this too. Currently our Burndown Chart is based on the most-right column Done. This is really a limitation, since we have another called 'Deploy' with issues that are done, but waiting for release. We do want those issues to be reflected in the Burndown Chart. This feature would solve our problem.

+1

+1 on this. In many workflows, there are multiple end-state statuses (e.g. Done, Dropped) and stacking them all in the last column of an agile is problematic. It is way too easy for a novice (or rushing) user to drag a task or story to Dropped rather than Done. And, as I stated elsewhere, if there is a transition to, say, Dropped but not Done from the current state, JIRA Agile will silently transition the issue to Dropped without any visual feedback.