Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,362,490
Community Members
 
Community Events
168
Community Groups

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

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

1 comment

John Funk Community Leader Nov 03, 2020

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. 

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 Community Leader Nov 03, 2020

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. 

Like Dharmesh Barot likes this

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.

John Funk Community Leader Nov 03, 2020

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. 

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events