Two status in one column won't let me choose both when moving task

[Torben Christiansen]

Hi everyone,

I'm facing a bit of a challenge with my Kanban board setup, and I hope someone can help me out. Here's the breakdown:

Setup:
I have a Kanban board consisting of 6 columns: Hidden backlog, Planned, Analysis, Development, Test, and Deploy. Within three of these columns (Analysis, Development, and Test), tasks can exist in two different states: "In XXX" and "Done XXX".

Problem:
While my workflow is mostly functional, there's a peculiar issue that's been bothering me. Allow me to illustrate with an example:

Let's say I have a task in the "Planned" column. I can seamlessly drag it to "In Analysis" - no problem there. However, when attempting to drag it to "Done Analysis," I encounter a visual obstacle. Unlike the smooth transition I expect, I'm unable to visually drag it to the "Done Analysis" state. Instead, I have to manually open the task and change its state to "Done Analysis" using the dropdown menu.

Question:
Why am I unable to visually drag tasks between these two states within the workflow? Is there a fix for this issue or perhaps a workaround that someone knows of?

My workflow is as following: 

I'd greatly appreciate any insights or solutions you might have on this matter.

Thanks in advance!

[Matt Parks · Accepted solution]

Are you saying that you can transition from Planned into Analysis Done directly on the issue, but not from the Kanban board?

If so, that seems very strange, as I don't see a transition from Planned into Analysis Done, so I'm not sure how you could do it from the issue.

If, however, you're saying that once the issue is in "In Analysis", you can transition into Analysis Done from the issue but not the board, this also doesn't seem to be expected behavior, as transitioning the issue directly from the View screen isn't any different than transitioning it from the Kanban board. In that case, I would double check your board configuration to make sure that all of the columns/statuses are mapped appropriately.

[Torben Christiansen]

Hi Matt,

It's pretty hard to explain what's going on but I'll try again. 

I can't (visual) drag the task from "Planned" to "Analysis done". My workflow is taking care of this and that's great, because that shouldn't be allowed.

However what I'm trying to do is (and maybe I wasn't clear enough in my first post) moving my task from "In Analysis" to "Analysis done" - I can't do this by dragging the task on the board. I need to open the task, change the status and then close it again, before Jira is moveing it. 

I was hoping that it was visual possible to drag the task from one state/status to another in the same column just like you can if you're moving a task from "Planned" to "In Analysis", if that makes sense at all?

At the moment my columns and statuses setup in Jira are as this:

[Matt Parks]

Ok, I understand what you're saying now.

Unfortunately, this is expected behavior. If the two statuses exist in the same column on the board (which it sounds like "In Analysis" and "Analyis Done" do on your board), then you can't transition between the two statuses on the board. Transitions are only allowed on the board if the source and target statuses are mapped to different columns.

[Torben Christiansen]

A bummer! But thank you for the answer anyways, Matt!
But just so I fully understands; I can still make a task transfer from "In Analysis" to "Analysis done" when open the task right?

Like this:

[Matt Parks]

Yeah, as long as the transition is allowed in the workflow and you meet all of the conditions (if any) on the transition, you can always transition the work item.

[Torben Christiansen]

Alright - kinda makes sense now. I just thought it was visual possible to do it the other way. But I think it's good for now.

Thank you for your kind help, Matt!

[Yuval Yeret]

Unfortunately, this is expected behavior. If the two statuses exist in the same column on the board (which it sounds like "In Analysis" and "Analyis Done" do on your board), then you can't transition between the two statuses on the board. Transitions are only allowed on the board if the source and target statuses are mapped to different columns.

@Matt Parks  I'm curious as to why this is the "expected behavior" JIRA chose to implement. 

In my kanban/flow coaching I recommend teams clearly distinguish active and queue states like @Torben Christiansen shows here, which really helps with flow metrics and understanding. 

AND I also recommend the WIP limits span both the active and queue state - because it creates a better pull system - it always allows you to move an issue to its subsequent done lane (because its under the same WIP limit), and it connects the lane to its downstream by enforcing the wip limit on both the active and subsequent queue. In this case "in analysis" and "analysis done" should indeed be under one WIP limit, which will make sure that if development is becoming constrained, we eventually send a flow signal back to analysis to stop creating analysis inventory. 

In this recommended definition of workflow, moving a card from the active to the queue "in analysis" to "analysis done" is actually the "happy path" which most issues will flow through, which makes it a bummer that you have to do it manually via the state change, rather than drag and drop on the board. 

This limitation Torben found has come up in a couple of flow system redesign/acceleration workshops I've done with clients recently. I was initially quite surprised that the in-column drag and drop didn't work. My clients were very surprised as well, and kept looking for a transition limitation until I showed them it works when you trigger the state change manually or configure the states as separate lanes (which has severe downsides as described above) 

Any chance to reconsider the "expected behavior"? I'm happy to discuss further if its useful.

Yuval Yeret
Professional Scrum Trainer | SAFe Fellow | Co-author of the Kanban Guide for Scrum Teams | co-creator/steward of Professional Scrum with Kanban

[Matt Parks]

@Yuval Yeret   I  have no idea why Atlassian decided to implement it this way, as I'm just a guy who administers Jira, not someone affiliated with Atlassian in any way.

I'm just saying how it works, not that it's the optimal way that it should work.