Should I alternate To Do, In Progress, and Done status categorizations within a Kanban workflow?

[kevin.caldwell]

I'm curious to understand what the advantages or disadvantages of alternating Status Categories within a single workflow would be. 

For example, should I alternate between To Do and In Progress to separate upstream and downstream Kanban, before finally reaching a status category of Done?

Would this impact the built in reporting that JIRA does in a non-optimal way?

Thanks!

[Bill Sheboy · Accepted solution]

Hi @kevin.caldwell -- Welcome to the Atlassian Community!

If I understand your question, you are asking about comparing something like this (ignoring the status category values for a minute):

A) To-Do  Developing                Testing                 Releasing  Done
   =====  ==========                =======                 =========  ====


B) To-Do  Developing  Dev-Complete  Testing  Test-Complete  Releasing  Done
   =====  ==========  ============  =======  =============  =========  ====

• (A) only shows the workflow steps where work is happening.
• (B) also has "queue steps" where work accumulates until the next person with capacity can pull it to start.

Some teams prefer (A) to make it easier to manage WIP in a tool like Jira.  Others prefer (B) to recognize the need for buffers and to measure the waiting versus working time better.

For either, the status categories do not seem to have much impact for Jira's built-in Kanban reporting.  Addon app reporting might look at the the category, but they are more likely to use the board's column mapping to help the team manage flow.

Kind regards,
Bill

[kevin.caldwell]

Thanks, Bill. That is what I was looking for.

[Norma]

Hello!

Are you having any impact on metrics, having alternate status categories in the team's boards?

[Bill Sheboy]

Hi @Norma -- Welcome to the Atlassian Community!

First, the status categories in Jira have no substantial impact on the measurement features.  Instead I was describing the different flow areas of:

• not started,
• started processing (i.e., Working),
• completed with processing step and waiting for pull to next (i.e., Waiting),
• ...
• completed

From a process perspective, buffer states help to solve specific problems with flow and  / or help a team transition toward single-piece flow.  Unfortunately, the built-in Jira indicators for WIP limits cannot span columns (e.g., the working and waiting states) and so this can lead to confusion and WIP problems...which may increase total durations.  One mitigation for this is the people on the team need to pay attention before pulling work.  Another is to investigate marketplace addons which improve WIP limit management on boards.

From a tooling perspective, the built-in measures for Jira Kanban boards are quite limited, in my opinion.  With the buffer states there is no impact on Lead Time measurement, but it makes seeing work vs. wait time quite challenging.  The Atlassian interpretation of a Control Chart does not have (again, in my opinion) sufficient options to do so.  Marketplace addons or home-made measures can be better, and will support VSM analysis of work flow.

Kind regards,
Bill

[Norma]

Thanks for your sharing @Bill Sheboy !

Best regards,

Norma

[Iryna Komarnitska_SaaSJet_]

Hi @Norma 
Welcome to the Community!

If you're interested in time metrics and how to interpret and measure them, I can recommend articles written by my team:

• Time in Status in Jira: What is it and how to track?
• Insights from Time in Status, Cycle Time, Lead Time and beyond metrics
• From To Do to Done: Analyzing Time Duration Between Statuses

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

I can't think of any advantages of doing it.  Once an issue has started in its lifecycle (i.e moved out of some form of planning or just "needs looking at" to-do type status), then surely it's in-progress, right until it is delivered.

[kevin.caldwell]

Thanks, and thanks.