0

Problem

My team consists of software developers and UX designers. Their workflow is different--UX has different steps than a pure development task has. What's the best way to manage this on one Kanban board?

bonus: what's the best way to manage this in Jira's Kanban?

Details

With our project, we have UX folks conducting stakeholder interviews, building wireframes, and getting approval. Their steps are something like:

  1. Interview stakeholder
  2. Design wireframes
  3. Developer feedback
  4. Stakeholder Approval
  5. UI Design (colors, etc)

We also have developers with their own flow, like:

  1. Ready for Work
  2. In Progress
  3. Code Review
  4. QA
  5. Product Owner Review
  6. Deploy

Some of the stories the designers work on feed directly into developer stories, so it would make sense to have a board combining all team members' steps. However, sometimes there's design work that won't directly lead to a dev story--basically, design stories will skip steps in the flow.

Thanks for your help! 🙇‍♂️

1

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:

  1. Ready
  2. In-Progress
    • UX
    • Coding
    • Testing
  3. 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.

1

JIRA boards are effectively views on to projects. That means it is possible to have many different boards containing the same data (or a subset of the same data).

For example, you could have a developer board, a UX board and a combined board all pointing at the same project. All JIRA needs is a way to work out which tasks to show on which boards. For example, you could use a custom field or a label and use that in JQL in a filter to define the boards.

It would be worth getting the team together to have a think about what purposes you want to use the boards for as this will determine the columns on each board and the JQL for the filters.

From experience I would suggest you are unlikely to get this right first time. I would recommend creating several boards and then inspect the results after a few weeks to determine which boards are working well and which boards need to be modified.

0

INVEST

Some of the stories the designers work on feed directly into developer stories

Here is your problem.

Take a look at the INVEST mnemonic.

I - Independent - The PBI should be self-contained, in a way that there is no inherent dependency on another PBI.

You are taking a single story ("Make the alpha widjet fuzzy") and splitting it into two non-independent stories ("Make the alpha widjet look fuzzy" and "Make the alpha widjet act fuzzy").

What you should do instead is have a single Story that contains Sub-Tasks.

However, sometimes there's design work that won't directly lead to a dev story--basically, design stories will skip steps in the flow.

That's fine? Just allow the Issues to transition how the user wishes.

If you want stricter/prettier functionality

The above will work, but has some clunkiness.

An improvement I'd suggest would be to add different types of Sub-Tasks. Then you can:

  • Assign them to different workflows (e.g. Design-Sub-Tasks don't have Code Review).
  • Have three boards - one that shows everything, one for development, one for design.
  • Add Quick Filters to the main board.
  • Including design work with a specific story makes sense, but there are situations when design is not directly related to specific story: stakeholder interviews, overall site look and feel UX. These types of design stories aren't part of any specific implementation story. I thought about sub-tasking, but I didn't find it worked very well on a Jira Kanban board: you could have sub-tasks in progress but the actual story is still shown as being in the backlog--you get a discontinuity, making it hard to really know what's going on with the story. – John Gordon Oct 4 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.