Configure board with multiple Todo/Done columns?

[John Horvath]

I have several statues that I want work to be in a "todo" or "done" states (yet still ordered). But the board only appears to allow a single "todo" column (the first) and a single "done" column (the last). Is there any way to put in multiple columns for these statuses? I can't seem to find a way....

For instance I would like to have:

todo

todo

in progress

in progress

in progress

in progress

done

done

but the second todo and the first done are both labeled yellow columns (i.e. "in progress"), even though the associated statuses are not "in progress".

[Kannan]

I recently wanted to move from Scrum to Kanban in Jira and disappointed that there is no 'done' for each stage. The community and the product management of Atlassian does not seem to be hearing the need of users, but rather try to force fit current Jira functionality to what user needs. That is a sub-optimal solution and leads to dissatisfied customers. If you say, Jira is only for Scrum and not for Kanban, that is perfectly fine. Or acknowledging that some features are not available but in pipeline, is also fine. But saying that there is Kanban and not having essential features for pull mechanism which is to have 'done' column for each stage makes the product inferior. 

[mrcertified]

Please, stop rationalizing lack of functionality with some "there's only one proper way to do things" BS.

I don't need your help setting up my workflow. If I conclude I want to have one DONE column - I will set up one such column.

This is clearly something users want, it's incredibly arrogant to say that "no, users should do it our way because, we know better".

[Nic Brough -Adaptavist-]

It's not BS I'm afraid.  Atlassian have chosen to do it this way because that's the way the methodology works.  It has a simple "done is done" approach and "done but not" means you aren't doing it that way.

If you don't want to do things the Scrum or Kanban way, that's fine, but you can't expect software built for those processes to support something totally different.

[CCI]

You sound like the "I wasn't vaccinated as a child and lived" type person, using your single experience to drive the way others should do things.

Scrum/kanban are methodologies, not defined specs. Quit getting hung up on the word "done". If it helps call it something else like "complete" or "finished". In a multi-stage process, there is the "done" for each stage, and the done for the process. No different than a Jira issue with subtasks. You can mark the subtasks done while the parent issue isn't done.

Not everyone works in planned, organized, well coordinated teams. In my business case our development is quite ad-hoc. We have a single development team working on multiple concurrent projects, and some of those people are involved in non-development work as well. We do plan releases, but there is not dedicated spec/dev/qa/etc time for that project. It gets done intermingled with other work. Having a lot of simultaneous projects going on at once for the same small group of people is difficult to keep track of. Simply having a way to mark the stage "QA" or "Documentation" as done would be immensely useful.

In a workflow that goes from code > deploy to test > qa, if the issue is currently in the "deploy to test" stage and gets deployed, I don't want it to immediately move to QA, because that isn't it's true state. It might not be QAed for weeks depending on existing workloads.

It's easy to say that this is poor organization, but you've gotta keep in mind the people requesting these features often aren't the same people who get to manage the budget, hire people, etc. They need tools to get their work done effectively. It's hard to change human behavior but it's much easier to change software to work the way people need it to.

[Deleted user]

From my perspective the current implement derives from Scrum, which has a simple view on process.  

I don't think the current approach in Jira supports Kanban well.  Kanban has a more nuanced view on process than Scrum, and the proposal is to enable Jira to support this. 

[Nic Brough -Adaptavist-]

To respond to the

I'm afraid I'm exactly the opposite of the anti-vaccination fool you compare me with.  I work from the information I have, which has lead me to the answer I gave you before.  Nothing you've said gives me new information.

Jira already fully supports Kanban, that's the point I'm making.  If you're doing it differently, fine, but it's not really going to be Kanban, and Atlassian probably aren't going to support it.

[webDevelMike]

If Jira fully supported Kanban, it would allow for a WIP limit to extend across multiple columns, no?

[Nic Brough -Adaptavist-]

No more than it already does.

[Jeff Mahnke]

"Agile Project Management with Kanban" by Eric Brechner is an excellent resource for understanding of the functionality being requested.  Each stage in the Kanban workflow is split in two, e.g, Verification stage of the workflow has an "In Verification" and "Verification Done" columns within it.  This is not to be confused with the Done stage (i.e., Done, done). The request is simply for a pair of columns for each stage in the workflow. 

[Jose Seravalli]

It's really sad and disappointing that whenever I search something in here it's basically the community "leaders" or the JIRA developers telling the actual paying users that they don't know anything. Differentiation between `inprogress` and `ready/done` in a single column is really useful to establish a "pull" mechanism approach when moving tickets through the workflow in kanban(which adheres really well with the origins of kanban), and it's completely unjustified the push back for this request in this post. 

As someone suggested above, "Agile Project Management with Kanban by Eric Brechner" it's a good place to start in order to understand this feature request instead of pushing back with "JiRA IS DoING ReAl AgiLE aNd EvErYONe eLSe iS WrONG AnD DoInG WatErFAll" ;)

[Dejana Erich]

For the timebeing, I have solved this by creating custom statuses and matching columns to better reflect my team's actual workflow:

I did not implement multiple "Done" columns; instead, tickets simply get dragged from our custom "In Progress..." column to the next custom "To Do..." column in the workflow (E.g. once you complete an "In Progress Content" ticket, you would simply move it to the next column in line--"To Do Design", in that case. A designer would then grab it and move it to the "In Progress Design" column, and so on.).

Note; anything flagged with the default/generic "To Do" status ends up in the Backlog, waiting to be triaged, before it even makes it onto the board. I have disabled the default "In Progress" status altogether.

I'd be happy to hear thoughts / better solutions!

[Kannan]

Dejana, that is great workaround. Thanks for sharing. 

I am left wondering though as to why after licensing a commercial tool, should we resort to workarounds. When I look at the comments posted against having multiple done columns, I can see that all those are from Scrum world and for them, there is only 1 done. But do they understand the needs of "other" groups of people for whom this is required. Just to rewind back, when microsoft project only was there, there was no 'done' at taks level at all. If the Scrum folks asked for done and microsoft project folks say that 'done' is meaningless and only feasible if the project fully is done. So, I can see the same thing happening here. In Kanban, there is a 'step level done' and in Scrum, there is a task level done. The last step done in Kanban is equal to scrum level done. I am sure if Atlassian says it supports Kanban fully, it should provide step level done in addition to task level done. Otherwise, it should not call it Kanban board and let down people. 

[Brett Wyrick]

I just discovered this Chrome extension, I think it'll also work for what you're doing: 

https://chrome.google.com/webstore/detail/jira-cloud-kanban-combine/bpjcmpaglmkolfbceeepffndplfbdkcb?hl=en

[Nic Brough -Adaptavist-]

No, the far right column is "done", the others are not.  You can put many status into "done" though.

[CLC]

I cannot believe JIRA is so out-of-date: you just cannot do anything when using kanban.

- doing/done: not possible

- done rules: not possible

- building a free-transition workflow because you don't care about statuses: not possible

When is JIRA going to catch up with other Tools like Azure DevOps for kanban users?

[Nic Brough -Adaptavist-]

Technically, Jira is well ahead of Azure DevOps, because it implements the basics of Kanban correctly, whereas Azure lets you pretend to be Agile while falling back on to waterfall patterns.

[Jeff Mahnke]

@Nic Brough Have you read "Agile Project Management with Kanban" by Eric Brechner?  I would be very interested in collaborating with you or any interested community leader and/or jira product manager.  I almost have jira supporting the "pulling" kanban approach, but with a couple of remaining oddities.  Would very much appreciate consultation and an opportunity to share and provide feedback.

[Brian]

Concur, my interest is in having the flexibility to set up like this:  https://www.visualstudio.com/en-us/docs/work/kanban/split-columns

Nick, here is a link so you can learn more about Kanban and understand the importance of unique quality steps for done.

https://www.google.com/search?q=eric+brechner+spreadsheet&rlz=1C1RNLH_enUS518US518&oq=erich+brechner+&aqs=chrome.2.69i57j0l5.9455j0j4&sourceid=chrome&ie=UTF-8

Done has a differerent meaning for analysis/specing, building software, testing software, and releasing software.  When I'm done with my spec, I can start building my software. When I'm done with my software build, I can start testing.  When I'm done with testing, I can release.  Each done has separate quality rules, it wouldn't make sense for me to apply the done testing rules for integration testing to my analysis/spec or release. That is why there is a need for Active and Done sections or split columns.

[Nic Brough -Adaptavist-]

You already said that, and I've seen all of this before.

I've already explained the failures in it above.  Not the split column stuff - that's not strictly necessary to do in JIRA, as you can get close to it without the feature, but it would still be a useful thing to have. 

The failure is the multiple done.  It does not work.  You need separate "done" status with different names, or it's a miserable failure.

[Chris Kite]

I'm going to also have to disagree here. The only failure of ambiguity with multiple Done columns is if your team is not intelligent enough to know that saying "done" with no context is a problem. It takes a couple extra seconds to just say "spec is done" vs "this is deployed to production". And in fact, none of that needs said if you have a Kanban board with the split columns because you can SEE where it's at. No one has to ask anyone anything.

We have the same problem. If I have a column for "In Progress" and "Testing" We don't want to immediately move it to Testing once the In Progress/Coding is done. We wait for all of the issues to be finished and then they get pushed to test. They need a place to sit where they are done with development but haven't been staged or pushed to test yet.

All I want to visually see is "okay all of the In Progress (coding) work is no longer active, it is done. Now we can push it to test. Then once testing is no longer active and is all done, we can push it to documentation, etc"

Not everyone has automation and build systems that can help  coordinate all of this. Nor can you just flip a switch move to Scrum. Smaller teams don't have the luxury of refined roles like product managers or development managers, etc. Many people often wear many hats.

I think that's why Kanban is the way it is, and is best for small teams. If you have a larger or more structured team, then use Scrum.

[Ciwan]

I agree with Chris here. We really need this feature on Trello. @Chris Kite am I right that this cannot be done in Trello right now?

[James Saxton]

I love the fight back throughout this feed on many customers of this product asking for a feature that is used on physical boards to allow for their processes to follow suit on a digital board, yet the response is a firm anti agile answer.  The very nature of saying no you can't do that, it is anti agile.  The nature of agile is that adopters should be able to be agile in their approach.

I would advise champions(?) to actually listen to customers needs and maybe begin to champion that.

[Brandon Adams]

Agree with those requesting this functionality and referencing good material to support it such as Brechner's book.  There are no shortage of educational resources from articles, books, videos, and classes available to supporting this request.  I too don't understand the close-mindedness of some of the responses.  

[Deleted user]

I'll chime in as well.  To run a proper Kanban workflow we need to be able to divide status values after "ToDo" into two parts: "In Progress" and "Done".  The "done" part is queue. The "in progress" parts are the actual activity. Time in the queue is waste and we want to minimise it, we can only minimise it if we make it visible.  This is true for every status.   

For example, statuses might be 

ToDo

Define (which can be "In Progress" and "Done")

Build (ditto)

Test (ditto)

Release (ditto)

Jira seems to mandate that Kanban teams model this with lots of separate statuses, e.g. Define In Progress, Define Done, etc. But that is quite clumsy when, conceptually, every step in the process needs to be split this way.  

What the Scrum community call "Done" would be "Release Done" in the above example.  That is a good goal, but it ignores important elements of the workflow before that point. Not all teams are Scrum teams.

I've set my team to find a workaround, but it is strange that we need to workaround when the need is a fundamental of our chosen lean-agile approach.  

[Brett Wyrick]

Looks like you can do this with a Chrome extension - check this out:

https://chrome.google.com/webstore/detail/jira-cloud-kanban-combine/bpjcmpaglmkolfbceeepffndplfbdkcb?hl=en

Not an ideal workaround, as it seems you all want this within JIRA, but if everyone on your teams downloaded this Chrome extension, it looks like it'll do what you're wanting it to do. 

[Christi Heatherly]

Can this please be added as a community requested feature?  We use the Control Chart to show how our development portion of the process flows.  Without having the second "Done" column, they are effectively penalized for the time it takes our PO and Business Partners to review and resolve each request.  

We roll each of our teams up to an overall control chart by area, so I do not have the ability to select the columns within the Control Chart at that level.  Only the state of the columns.

As a workaround, we have multiple states in the Done column....this is really confusing for our PO and our partners.

Please add as a future enhancement.

[Nic Brough -Adaptavist-]

It was added a while back (see Jira.atlassian.com), but Atlassian closed it as "won't do"

[Christi Heatherly]

There is an open ticket for this issue that has 51 votes currently to address:  https://jira.atlassian.com/browse/JSWCLOUD-12169

Ticket is JSWCLOUD-12169.

While on the Cloud board, it hopefully will translate to all versions

[petecog]

I'll chip in, we have a need for multiple 'flavors' of "Done". To explain: We use Jira to items to track potential bits of work, e.g. bids.  An bid has a well defined workflow, but can terminate in an number of different possible endings. E.g. Bid accepted, Bid rejected, Disappeared (e.g. we never hear back)

[Matthew Fanning]

Hi there,

I too would like to have multiple 'done' columns.

We have our columns set up as follows:

PBIs in Sprint - Todo - Doing - Complete - PBIs Done

Our Todo, Doing, Complete columns are where our devs live.

The PBIs in Sprint and PBIs Done are where our stories are. This is where the product owner lives.

In our sprint planning meeting, the devs build up tasks based on the PBIs in Sprint column, and populates the Todo list. Over the course of the sprint, these tasks move through Todo, Doing and Complete.

When all tasks are completed, and the definition of done has been completed for the story in the first column, the story gets moved over to PBIs done.

This works great, up until we hit finish sprint. The tasks that are in the Complete column aren't marked as done despite having completed the task.

What I don't understand is why you can set the resolution to done in the workflow, which then effectively does absolutely nothing. I don't understand why you would have this feature, only to not use it in a scrum board?

Thanks.

[Nic Brough -Adaptavist-]

The resolution flag for "issue is complete" is part of plain Jira, from well before Greenhopper was written and introduced boards.  It's not that useful in terms of boards, because boards are built on status, and suddenly having the "done" column work of something else is not that intuitive (plus Jira allows you to make a mess of resolution in your workflow if you're not careful, which makes it worse)

Personally, I think the resolution should have been dumped in favour of relative meta-status a long time ago (the field is fine as "why we closed it", but shouldn't be used for "does this need further work")

[Bill MacMeekin]

I agree having only the last column defined as done does not work. In a large enterprise when developers are complete with development and QA we move to a UAT column which is our business partners testing the delivered app. The UAT process is not part of our Sprint nor do we have control of when they test. However from a development and completing the sprint we need to deliver all committed sprint goal work to UAT. If you get all work in UAT at the end of your sprint and then try to use Jira's burn down reports it does not think the work is done.   

[Nic Brough -Adaptavist-]

I'm afraid it does not work to allow many.  If it's in UAT, then it's not done.  It might be done for one team, that's fine, but they they should be using a different board to a team that does not consider it done.

[Austin_Graham]

We have this same problem, but once it is in UAT and tested by this other team and "done" for them, then it has to come back to our team to move to production. So the workflow is To Do > In Progress (multiple stages) > UAT (out of our hands for the time being) > Release to Production (back to us with a few extra steps) > Done.

I have really been struggling to replicate this in any way on a board. The client is not super agile in that they want us to save up a bunch of items before pushing to production (release cycle is 3 months) but we still need to technically do work on them after UAT to prep them for the production release before we can move on and say they are complete. 

[Brian]

I have 4 columns, Backlog, Specify, Implement, and Validate. I'd like to have 2 columns under Specify, Implement, and Validate.  The two subcolumns are Active and Done.  The reason is that I have quality rules for each state, which need to be completed before the task can go to the next state.  For example, under Specify, the tasks need to be done in 1-3 days, and need a speclet, before they are done, and can be validated by a team member.  Or for Validate, unit testing, security testing, performance testing, and load testing all have to pass and be confirmed by a peer before they are done.

[Brian]

...this is for Kanban, not Scrum...

[Nic Brough -Adaptavist-]

You'll need to implement it as four columns if you want to see it as that (there's no "sub columns"), and ensure you have a single proper "done" column.

Everything else in that spec is workflow conditions and validators.

[Brian]

Right, I believe the original thread is about an electronic version of Kanban. In reading through this thread, it appears that there is some confusion regarding what done means in Scrum and what it means in Kanban. In Kanban, Done represents the quality rules that are in place at every stage. So there are a series of "Done"(s), based on the workflow.  I could have a value chain (workflow) that has 7 or 12 steps, and each of those would have an "Active" and "Done."

[Nic Brough -Adaptavist-]

That is very true, but Kanban has a poor model in using "done" repeatedly.  This does not fit with any useful workflow, and JIRA requires you to separate them properly because two "done" status is confusing and simply doesn't work in a logical workflow.  (Ask three of your humans if something is "done" and when they see it's in column E, two of them will tell you it's not, because more work needs doing).  So you'd have specify-active, specify-done, implement-active, implement-done.  And eventually, it should have a "done", as in "nothing else needs doing".

The weakness in JIRA in my opinion is that you can't define your own meta-status, we're stuck with to-do, in-progress, done.  I'd like to be able to define my own meta-status (line 1 in your diagram)

[Brian]

Respectfully disagree, I believe the ask is for Jira to snap to the industry best practices. Not for Kanban to snap to Jira software constraints. 

[Nic Brough -Adaptavist-]

It should indeed follow a best practice, but this particular one is NOT a best practice - it's awfully broken.

When you have multiple "done" status, or ones that are subjective, there must be a way to differentiate them clearly at all times.

There's nothing wrong with Kanban's idea of different dones within meta-columns, but it's completely broken when you can't tell the difference between the dones.  A Kanban board *with no other display of the information* works fine, because it shows the columns.  As soon as you have any other reporting, it's broken.  Unless the reporting shows the difference.

[John Horvath]

Once again, just to chime in, I really would like JIRA to enable me to get my work done, mirroring my real world workflow (which is proven and working for many years), but in software.

A flexible board (Kanban, Scrum, Kanum, Scruban, whatever...) is what I'm looking for. If being told "No, this it the way you do it, your way is wrong!" was even a valid response to this request (which it isn't), then Agile wouldn't even exist, and we'd all still be using black box waterfall development methodologies.

I just want the freedom to create a board that meets my needs, and not have to use two separate products to get the job done right, which is what we have to do now.

[John Horvath]

This is kind of an issue... as I'm trying to migrate from our real world Kanban board to the digital board provided by JIRA. We have several steps from backlog through assignment where no actual development is being done, but we like to track how far down the pipe that "pre-work" is... is there any reason JIRA does not support this? I mean multiple "in-progress" columns are allowed, why not allow it for all columns types?

[Paul Alexander]

With respect, this seems very anti-agile. There is only one "DONE" and a clear definition thereof must be identified and agreed to by your team(s).

[Nic Brough -Adaptavist-]

I'd +1 that if I could - more than one "done" column is not an Agile pattern.  Either it's done or it's not.

[John Horvath]

I would have to whole heartedly disagree, there are a variety of reasons a unit of work can be considered "done". Our team sub-divides "done" into work that has been completed, work that has been canceled, and work that has been deferred. Each of which is put into their own column within "done" so it's easily identifiable, track-able, and any hours put against those tasks are recorded appropriately. Deferred work is then replicated into the next sprint or the backlog depending on necessity. To say there is one and only one "done" is a bit too prescriptive in my opinion.

[Nic Brough -Adaptavist-]

I understand that desire, but could you explain when an issue is "done"?  It's a pretty black and white thing - either it's finished, or it needs more work.

[John Horvath]

It's all about context.

For us there are times when work has been started (within the context of a sprint) but cannot be completed. A client may, mid-sprint, decide they no longer want feature "A" so we canceled it (but we track the fact the work was started, hours still need to be charged, etc.). For all intents and purposes that work is done within the context of the sprint.

Like-wise there are times when work was just estimated poorly, but isn't identified as such until the work is actually started, so we end up deferring it. Once again in context of the current sprint the work is done, whoever in terms of the release it is not, but we keep it on the current sprint board for reference and generally create a new task to finish the work later (once again still needing to charge hours, etc.).

This process works for us, and using our whiteboard and sticky notes we've never had an issue. But now that we want to move into JIRA (in order to have better historical tracking, and scale up the number of teams and projects we can work on simultaneously), we're finding that the tool is limiting us... and those extra "done" sub-columns are all lumped into a single silo making it very hard to see the clear separations we have on our whiteboard.

My biggest question is why? I would expect to have the freedom to create any number of pre-work (to do), work (in-progress), and or post-work (done) columns to suit my needs. We currently use AxoSoft and it allows us to define our board in any way we want. However we plan to start using Confluence in the near future, and as such have been looking at JIRA and Bamboo to possibly replace AxoSoft and TeamCity respectively.

[Nic Brough -Adaptavist-]

But when is an issue done?  (Cancelling them is fine, it's a done status, as you're not going to be working on it any more).  The context is not relevant to the question, because it's either "more work needed" or "no more work"

[John Horvath]

To answer your question, a work item in JIRA (not the work itself) is done when the status is changed to any status within the "done" set of statuses. As I explained in my second example we replicate deferred worked as new tasks in subsequent sprints, but within the context of the current sprint deferred tasks are essentially complete, and no further work will be done on them. So context does matter.

The real issue here is that JIRA allows you to have multiple "to do" and "done" statuses, but won't allow you to place those statuses into multiple columns on the board, thus not allowing us to mirror our current real-world board. As I stated we have sub-columns in "done" categorized by status, and it's very easy to see what tasks are complete, what tasks were canceled, and what tasks will be continued at a later time (but are done within the context of the current sprint). In JIRA they're all lumped into one column, making it much harder to immediately discern the different statuses.

Which is contradictory to how you can have multiple "in-progress" statuses, each with their own column. I just don't see why allowing multiple "to do" or "done" columns is an issue, so long as those columns are grouped at the head and tail respectively with "in-progress" columns as the body.

We just want the columns allowable to go from:

To Do x 1

In Progress x N

Done x 1

 to:

To Do x N

In Progress x N

Done x N

If most people choose not to use that feature, that is up to them. But for those of use that want to use it, we're wouldn't be restricted from doing so. As I stated our real-world board has multiple "to do", "in progress", and "done" columns, and presently JIRA is not helping us mirror our existing visual workflow process.

[Nic Brough -Adaptavist-]

>a work item in JIRA (not the work itself) is done when the status is changed to any status within the "done" set of statuses

Ok, so those status all go in the "done" column.

>As I explained in my second example we replicate deferred worked as new tasks in subsequent sprints

That is not how sprints work.

>what tasks will be continued at a later time (but are done within the context of the current sprint)

Then these tasks are NOT done.

Your definition of "done" here is failing you.  Done is black and white - the issue is done or it is not done.  There's no "done but not done at the same time", it's one or the other.

[Jonathan Court]

perhaps 'Ready for Next' would be a better name though - far less confusing and no 'trigger' words as per 'xxx Done' :-).

The point of these sub-columns is because a Dev or BA cannot push a ticket onto the next stage when using a Kanban style and you need a way to inform the next stage that something is ready to be pulled and the WIP limits need to be applied across both sub-columns (i.e: 'In Development' and 'Development - Ready for Next' sub-columns have a combined WIP limit) - if everything is in the 'Development - Ready for Next' column then the devs have nothing to do and must join another stage to free up the blockage to clear the 'Development - Ready for Next' column so they can pull some new dev work.

[Roger Lawrence]

@Nic Brough -Adaptavist- We have a situation where we develop items for an external customer. So the items are considered "done" when the internal PM agrees they are done. This is shipped software. However, the Client also needs to accept the work is done.

So either I have a board that does not give me an accurate burn down (because everything is in progress until the client accepts this (Sprint Review at the end of the Sprint) - or - I get an inaccurate burn down because everything is "done" at shipped, and then "re-opened" at accepted.

It would be nice to have the burn down reflect when jobs are accepted by the PM as shipped, and only reopened if the client doesn't accept them (in which case they move back to the sprint log (To Do or Selected for Development)

So from a Dev perspective a task is Done as soon as the PM agrees it meets the acceptance criteria. From a Company perspective a job is done when the client accepts it meets the acceptance criteria.

Otherwise it is impossible to monitor progress through the Sprint

[Nic Brough -Adaptavist-]

Put both "(development) done" and "accepted" in the done column, that will make your development burn-down work.  That's what burn-down is about - predictability of delivery.   That's what you should be measuring across the sprint, as your customers are not part of the sprint process.

I suspect your client acceptance is not really a burn down, but you can still do it.  Have a separate board that shows development done and accepted separately (including maybe any other work during the acceptance process). 

[Alex Berliner]

@Roger Lawrence 

Hi Roger

Did you find a suitable solution for this? I am in the same position with my boards.

@Nic Brough -Adaptavist- Any specifics on how to do this? We only have one "Done" Status in Jira, I mean, we can create the "Dev Done" and the "Accepted" columns, but will it work if both have the actual "Done" status assigned to them?