How to handle workflows and statuses for tickets moving through different environments?

[Dharmesh Barot]

Hi,

We are on Jira Cloud. Various teams use slight variations of workflows based on project types.

All tickets go from Backlog to QA (Test environment). Usually in the same sprint.

From QA onwards variations happen.

For example, 

Project A - may have a BETA environment for UAT

Project B - may have BETA and a Pre-prod environment for another round of UAT

Project C - may have an integration environment to test end to end, BETA, and a pre-Prod environment

A ticket is resolved when it moves to Done, so potentially it could go

Backlog > QA > Integration > BETA > Pre-prod > Done

Teams would like to report on current sprint when tickets pass QA, but they are open because they have not gone through other environments, which may happen in Sprint 2 or Sprint 5.

What is your recommendation on the setup of workflows and board, so we can see sprint progress on tickets accurately?

Looking forward to an informative discussion.

Best,

Dharmesh

[John Funk]

Yes, our last column is Done. 

But we also do not do Sprints - we just use Kanban. We can report on where (meaning what status) the cards are in and how long they are in each status and our lead time - how long to complete each card from start to finish. 

[John Funk]

Work never moves backwards in Kanban. If it fails you create a Defect (sub-task type) or a Bug. A Defect means that something is broken and the parent story cannot move through the process until all Defects associated with it are fixed. Defects run through the same process as the story. 

Bugs are noted as something not working as intended, but it does not prevent the Story from being completed and shipped. The Bug will get fixed and deployed where there is time. 

The emphasis in Kanban is to finish what you start before starting brand new work. As it is completed it is shipped - Continuous Improvement and Continuous Delivery. 

[Dharmesh Barot]

Understood. Then, you move back the same issue if it fails in an environment?

I see the benefits of Kanban and visualizing the workflow end to end across environments.

Curious to know how you balance that with planning on projects? Similar to Sprint Planning in Scrum.

[Dharmesh Barot]

Thanks @John Funk for your quick response. That would be our preference too to have one workflow. 

What do your boards look like? Is your last column on the board "Done"?

How do you report on work completed in the Sprint, and when tickets move through other environments in later sprints?

Do you reopen/move back the same story ticket if it fails in an environment?

[John Funk]

Hi Dharmesh,

We have actually done something similar using a single workflow. We have all of the statuses in the workflow.

We then have a custom field called Dev Needs. That fields is a checkboxes type field where you could put in the values of Integration, Beta, and Pre-Prod. So a user could check one or none of those values.

Then the workflow has a transition from QA to Integration with a condition that the Dev Needs field must have the Integration box check. 

Same for going from QA to Beta. 

And same for going from QA to Pre-Prod

Then each of those would have a transition to Done. 

You just use transitions in the combination needed for the workflow needed based on the values checked in the Dev Needs field (or whatever you want to call the field). 

That way, there is one issue type for us and one workflow that is flexible.