Company-Managed Conflict: How to Decouple Dev Board Columns from Global Workflow Statuses?

[Sabrine Cardoso]

Hello Jira Community,

Our organisation is standardising on Company-managed projects to ensure consistent data and reporting across the company. I am currently configuring standardised workflows and need advice on solving a conflict between team visualisation and global reporting.

The Conflict: Columns vs. Statuses

Our development teams (the consumers of the board) require a highly detailed Kanban board with many columns to visualise their internal development steps (e.g., "Code Review," "QA Handoff," "Deployment Pending").

However, I've realised that every board column must be mapped to at least one unique workflow status.

• Resulting Problem: If a Dev team wants 15 columns, I am forced to create 15 unique global statuses in the workflow. This is problematic because our internal stakeholders only need to know three things: To Do, In Progress, and Done. Creating 15 statuses makes high-level reporting impossible and creates unnecessary confusion.

My Current, Flawed Solution

My temporary solution is to educate teams to use Epics for even small features that only have one story. This is a workaround that adds unnecessary complexity to the backlog.

What I Wish For (and Need Advice On)

Is there a standard or better way in a Company-managed project to allow teams to use the same underlying global status (e.g., "In Progress") associated with multiple board columns (e.g., "In Progress - Frontend," "In Progress - Backend")?

Or, is there a better practice for managing this Dev visualisation vs. Global reporting conflict?

Thank you for any insight!

[Trudy Claspill · Accepted solution]

Hello @Sabrine Cardoso 

Welcome to the Atlassian community.

With regard to the high level reporting:

Every status that is created is assigned to a Status Category. There are just three Status Categories - To Do, In Progress, and Done. These correspond to the lozenge colors for the individual Status values; To Do = gray, In Progress = blue, Done = green.

Every item will have a Status Category value based on its current Status value.

You can base your high level reporting on the Status Category rather than the individual Status values; i.e.

Project=A and statusCategory="To Do"

...will result in a list of all items from project A that currently have a gray Status value.

On the topic of having so many statuses/columns, I would suggest that more time be spent examining what problem the team is trying to solve by having so many statuses, and see if there is another way to solve it. For instance...

If your dev team wants to be able to track statuses relevant to their work, and the QA team also wants to track statuses relevant to their work, could that be done by using more generic Status values (To Do, In Progress, In Review, Done) and then using the Team field (or another custom field) to indicate the internal team who owns the item at that time?

Or, could you have an item that is for the dev team, traversing those more generic statuses, and when it is complete you automate the generation of a new item for the next team that takes in work based on completion of the first item?

Or, rather than using Epics and Stories, consider using Stories and Subtasks. Again, using the more generic statuses, but have a subtask per team. When all the teams have completed their subtasks, then the story is complete.

[Sabrine Cardoso]

Hey @Trudy Claspill!
Thank you for your answer!

Yes, you definitely gave me some good options!
I'll analyse with my teams what is best for them!

Thank you very much!

[Sabrine Cardoso]

(Answer deleted and added as a reply)