Kanban Isn't a Work Log
Kanban is a pull queue system that visualizes process gates and work state transitions. That means that each work item is pulled by the task performers from a previous queue when their WIP limits allow. Each board should represent a logical view of a single unified process. You can have multiple boards to queue work between independent or sequential processes, as well as supplemental boards to provide greater visibility into state changes within each column.
Kanban is not a ticketing system, and the inclusion of disparate or highly-variable workflows works against the framework. The inclusion of non-flow work states and queues within a single board creates noise because many of the queues will be not-applicable to a significant volume of the work items being visualized. Don't do that!
Multiple Teams Need Separate In-Cycle Backlogs
Part of the problem you're trying to express is that the UX and software people aren't actually on the same team. Multiple teams should each be working from a separate queue, rather than trying to cram each team's workflow into a consolidated view.
While having a single, higher-level product backlog is usually the right thing to do, each team generally needs to have its own Kanban board and its own visualized process for tracking state transitions. In scaled Scrum implementations, this is done by distinguishing between the Product Backlog and the Sprint Backlog for each team. Kanban is less prescriptive, but the same model should apply.
Ideas to Explore
JIRA is, at heart, a ticketing system. While it can certainly be used to provide Kanban functionality, it's important not to contort your process to fit JIRA. Instead, you should define your process, and then leverage JIRA's capabilities to map your workflow as closely as possible.
Less-Granular Queues
If you keep work items small, then it's perfectly acceptable in an agile context to treat columns as coarse-grained queues. Specifically, you could have a unified board that simply says:
- Ready
- In-Progress
- Done
and then leave it up to each team to implement whatever queues and processes they want to track work internally in a separate JIRA board.
Team/Role Accounts for Ticket Assignment
Another alternative is to stop letting JIRA's limitations as a ticketing system constrain you. Keep a consolidated board, but use team or role accounts as the single-assignee for tickets, and email distribution lists to ensure everyone on the relevant teams can still receive email notifications and such.
The team/role approach has the side benefit of keeping everyone informed of state changes. If you discover that the signal-to-noise ratio of keeping everyone informed of each state transition is too low, then you need to ask:
- Why does everyone needs to see the same visual representation of the system, rather than custom views of the processes in which they are directly involved?
- Why do UX and software development need to see the same columns, rather than pulling/queuing work at each team's process boundaries?
- Why do we have distinct workflows, where UX people aren't embedded directly into a cross-functional development team?
If the noise of keeping everything consolidated is too high, then decoupling or sequencing your boards simply makes more sense. If you have non-integrated teams, then your visualization should model that accurately. A tightly-coupled Kanban board implies a level of workflow coherence that may not actually exist in your organization, and that needs to be fully visible to everyone involved.
Map Existing Processes Onto JIRA
Separate vs. integrated workflows represent a set of business and operational trade-offs. Consider re-evaluating the X in this X/Y scenario, and ensure that you aren't letting the limitations of JIRA drive your processes.
Currently, you seem to have decoupled teams with separate processes and some inter-process dependencies. That should be the basis on which you model your Kanban boards, rather than creating an ersatz management dashboard with limited value to the process performers. Naturally management wants to see an overview, but a visual model that doesn't accurately map to existing processes is of extremely limited value to anyone.
Decouple Management Dashboards/Metrics from Workflow Visualization
If needed, consider developing a separate dashboard or report that pulls data from each relevant workflow. Don't pollute the work-stream with this, though. Real Kanban boards are to make a process transparent, not to substitute for other forms of analysis and reporting.
