How should Jira board columns be configured when parts of the workflow can’t be used yet?

[cvanduyn]

Hi everyone,

I’m looking for guidance on how to correctly configure Jira board columns when a team has a defined future workflow, but not all parts of that workflow are usable yet due to environment constraints.

Our intended workflow (once the full architecture is live) is:

• To Do

• Work In Progress

• Work In Review

• Ready for QA Env

• In QA Env

• QA In Progress

• Ready for Stage Env
• In STG Env
• STG QA in Progress
• STG UAT In Progress

• Ready for Prod Env

• In Prod Env

• Prod QA In Progress

• Prod UAT In Progress

• Done

At the moment, only the dev environment exists.

From a practical standpoint, work is considered “complete for now” once it reaches Ready for QA, even though it is not truly “Done” in the long-term sense.

In Scrum terms, this feels similar to an evolving Definition of Done. We know what “Done” will mean eventually, but we can’t execute all of those steps yet...

In Jira, issues are treated as “complete” when they reach the rightmost column on the board:

• They disappear from the backlog view

• They contribute to the burndown

• This is independent of whether the issue is in a Done status category or Resolved

Workflow

We’re debating between two configuration approaches:

Option 1
Map all statuses that we cannot yet use (In QA Env, QA Testing In Progress, In Production Env, etc.) into the rightmost column for now in addition to the Done status.

This results in a clean burndown and reflects current delivery reality, but it also hides issues from the backlog once they reach that column even though they aren’t truly “Done” in the long-term workflow.

Option 2
Fully elaborate the board with all workflow columns now and allow issues to progress only as far as possible each sprint.

This means work items remain open and are carried over sprint to sprint until the remaining environments are available, which makes sprint metrics (burndown, velocity, story points) harder to interpret.

---

My question is:

What is the recommended or “correct” way to configure Jira boards in this situation where the future workflow is known, but parts of it can’t yet be executed?

Is one of these approaches more aligned with Jira or Agile best practices, or is there a better third option that avoids distorting metrics or hiding meaningful work?

Thanks in advance

[Bill Sheboy]

Hi @cvanduyn 

First thing...Although I understand why you are fully elaborating your workflow into status values and board columns, in my experience, Jira is not a good tool for using a board with more than around 5-6 columns. 

It does not have features to collapse / expand columns and manage longer flows like other such tools, and thus quickly becomes unmanageable, often due to transition errors.  I requested collapse / expand features many years ago and have not seen any progress: https://jira.atlassian.com/browse/JRACLOUD-85706

Back to your question, I doubt there is a "correct" or "best" way to solve this need.  Instead, consider how your team wants to manage the changes over time.  For example:

• to do this incrementally, you could use your simple flow and gradually add the statuses / columns, changing to the new workflow when needed...or...
• you could modify the longer workflow to add a transition directly to Done when still skipping over the incomplete ones...leaving those status values as unmapped on the board; finally when the complete flow is in place, remove the "shortcut" transition to Done
• etc.

Kind regards,
Bill

[Iryna Komarnitska_SaaSJet_]

Hi @cvanduyn ,

Recommended: don’t configure the Scrum board for a workflow you can’t execute yet.

• Set your current “finish line” as Done (Dev) = Ready for QA Env (rename it to make this explicit).

• Make it a Done status category and set Resolution on transition so sprint metrics stay clean.

• Track QA/STG/PROD steps as separate linked tickets (or a separate Kanban “release/promotion” board). Add those later when environments exist.

Why not the others:

• Option 1 hides unfinished work by treating future steps as Done.

• Option 2 causes permanent carry-over and breaks Scrum reporting.

Also, if you’re open to using a third-party app, you might want to try Time in Status (built by my team). It helps you track how much time issues spend in each status, and it also lets you audit your workflow to see whether all statuses are actually needed and being used.