Best Pratcies for Jira workflow for tickets that move from dev to qa

[Debbie Weinstein]

We develop software and our jira tickets start out with PM who create user stories, then are assigned to DEV who work on them and once they're done with the work they assign the jiras to QA.

Our practice has been that when DEV completes work on a ticket they change the Status to Resolved.  QA tests Resolved tickets.  

The problem we now have is that we are using the PORTFOLIO plugin.  Portfolio will only estimate based on tickets that don't have a Resolution - only those with a value of Unresolved.  But when you Resolve a ticket, Resolution is automatically updated.

So i'm interested in understanding the workflow others use to track a ticket's movement from DEV to QA.  

Is a jira set to Resolved ONLY after all work is done on it?

Thanks.

[Warren]

Hi @Javier Bastante 

It's all set up via Board settings -> Columns.

If you look at the screenshot below of our main board, you'll see that there are numerous statuses lumped into the Resolved column

Whereas, on what we call our "Releases board", those statuses each have their own column to give better visibility into what stage we are with the release.

You'll need to be a Jira Admin to create the extra statuses and adjust the workflow as required, then from within each board, click on the 3 dots at the top right, select Board settings and click into the Columns tab

[Javier Bastante]

Thank you @Warren for your fast and thorough reply. Very helpful!

Tried to create an additional "releases board" and tie it to our project, but the system won't let me do that. It doesn't give me any projects to choose from. 

Will do further research.

Cheers.

[Warren]

Hi @Javier Bastante 

If you're using a Next Gen project (I think it's now called Team Managed?) that's a totally different story, I haven't ever used them.

[Jason Christina]

Completely agree that it would be different at every organization and could be different within teams at an organization. It all comes down to what works best.

I think setting the resolution once the change has been deployed and validated in the production environment makes the most sense as that's when it's truly resolved from my perspective.

Before that point you could have a workflow with each status you work through (dev, test, uat, etc) and a board with each of those mapped to a matching dev, test, uat column or you could pull them all into an In Progress column.

Everyone will want to look at it in a different way and Jira's flexibility is what I like about it the most.

[Warren]

Hi @Debbie Weinstein 

I suspect that if you ask this question to 3 different companies you'll get 4 answers.

We have a Test column and then a Resolved column, so once it's passed testing, the resolution is set.

But ... our complication is that we test in 3 different environments (Dev, UAT and Live), so the testing I speak of above is just for Dev. We then have another board which shows the workflow through releasing and testing on UAT and Live. If it fails at any point on this board, it gets "Reopened" and the process starts again.

You need to think what suits your process best.

[Javier Bastante]

Hi @Warren what you described is exactly what we would like to do. Do you mind pointing me to more information on how you have your additional board setup? 

Thank you much!