Configurable Kanban columns other than status?

[Mike McGowan]

The documentation on Kanban column configuration is very clear – Columns are based on global statuses – I am wondering if anyone else ever felt the need try JQL (even if it disabled drag & drop).

If you ever felt that need, what did you try instead?   I am considering using Confluence columns backed by JIRA filters.    Any other suggestions welcome.

[Nic Brough -Adaptavist-]

Technically, it's not a Kanban board if you're not using "columns = position in the process"  (and that's determined by status in JIRA)

But, for non-Kanban boards that look like Kanban, have a look at Comala's Canvas.  It looks a lot like a board, but you can use many different fields, you're not limited to status

[Olivier Bogart]

I have now seen 2 thread about this question for decoupling JIRA boards: columns to status 1-1 relationship. 

There was another thread were it was mentioned it (Nic B.) was a good thing that JIRA was inflexible around mapping column to status and that asking for say to have the same status across 3 columns was heresy. I cannot more disagree, for instance you may have a corporation that wants reporting on workflow status transition across all teams in the corporation, but each team may use different process steps to start , progress and finish their work. by forcing everyone to use the 1-1 mapping the corporation cannot allow their team to visualise their work by process steps.  instead creating black boxes where process steps bottle-necking the delivery are invisible. 

for example one team (a) may need a peer review after code completion, some team (b) may not. does that means that team (a) will never be able to visualise what work is under peer review. simply because the least common denominator does not include "Peer review" across all teams and would stuff up metrics and reporting on status transition.

i am sure the experts will get to my jugular just for daring contesting the consistently misleading advice given. the point is that Jira is limited to this regard and that's annoying. 

in TFS /VSTS we can create any number of columns mapped to the same status, changing status when changing column is optional,  and to track which column a card is in there is a "BOARD COLUMN" field distinct from the status field. It can be used to find where the work item are on the Kanban independently from the work item status and report accurately on work in process.  furthermore in TFS / VSTS we have a definition of done for each process steps and each column can further be split in doing and done section. this is extremely useful and is inline with the true spirit of lean and kanban methodologies.

Opiniated views from educated community members (so called experts) can be a limitation to progressing Jira behind what is is capable of now. Jira like everything else needs to be improved.

[Stuart Donaldson]

I've led multiple teams in large organizations, and agree completely with @Olivier Bogart on this.  Agile teams in larger organizations often haft to map their teams practices into the organizational structure.  In Agile, we want to empower teams to be self organization, but often have some higher organizational requirements that are applied as constraints.  JIRA should enable the flexibility at the team level.  

Ideally, teams could define their own issue types and statuses, or maybe sub-status.  However, it does not work that way now, so the idea of some other attribute of an issue to cover the status within the team's workflow has an appeal.

[Mike McGowan]

Agree 100% on the "not a Kanban".    Currently, the development process is chaotic enough that the status field is not the greatest challenge.   Currently, need a more flexible board w/out going all to way to something like Trello.   This looks like it good do the job (and then some).   That said, the "I am considering Confluence" means picking a similar set of pages I had previously created and modifying them.