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".
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.
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!
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.
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?
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.
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.
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 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.
>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.
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.
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.
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."
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)
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.
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.
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.
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.
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.
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.
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.
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.
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?
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")
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)
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.
Looks like you can do this with a Chrome extension - check this out:
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.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events