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".
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.
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 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.
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.
If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot