Workflow Status Best Practices for Software Projects That Promote Across Dev, Stage, and Production

[Chris Olofson]

Is it a best practice to add Workflow Statuses which explicitly identify the environment a particular software issue has been promoted to?

Today, we use Jira to manage a software product which has environments for Development, Staging, and Production. Today, our workflow spans EVALUATING --> DRAFTING --> BACKLOG --> SELECTED FOR DEVELOPMENT --> IN PROGRESS --> CODE COMPLETE --> IN REVIEW --> QA PASSED --> DONE

An internal suggestion has been made to add workflow status after IN REVIEW such as

• IN STAGING
• STAGING / QA PASSED
• IN PRODUCTION (as a replacement for DONE)

Is this a good idea? Or should other fields besides Workflow Status be used to identify the environment (whether development, staging, or production)  to which an issue has been promoted?

I realize different people handle this in different ways, but I'd welcome advice from experts about what has worked best / what has not worked best. Thanks.

[John Funk · Accepted solution]

Hi Chris,

Probably not what you want to hear - but it's really up to you and how much detail you want to track. The question becomes whether you need to report on it by time in status through the various stages, or to report how many issues are in any one particular status at any point in time. 

If you don't need to report on it, then it is best not to capture it and make a bunch of extra steps in your workflow. A general rule of thumb is that as an organization or team matures, it has fewer and fewer statuses/steps in the workflow. 

[Chris Olofson]

Thank you!

[Rebekka Heilmann _viadee_ · Accepted solution]

Hi @Chris Olofson 

I would say it depends on whether a lot of teams are using the same development workflow or if it is just one team that has this requirement,

Also, things I always consider:

• Is it different people doing the different steps or is it one person?
• Do I need to differentiate the steps for reports or any views?
• Do I already have the info elsewhere, for instance if a Git-Repo is linked?

The only other option I would see for that use case is a custom field (Single Select e.g. Drop down). Downside of a field is, that you cannot use that to move issues on boards.

[Kelly A_ Burnett]

I was curious along these line of logic also, so I appreciate this thread. Our process has a step that I am unfamiliar with, after watching and listening, essentially, it is another QA step after the development is complete. My first instinct was to delete that step, but listening and discerning is the wise move. Glad I sat back and listened. Hope this lesson learned serves others.