nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Questions about Jira workflow when resolving issue at QA phase

Mayte Eme

Hi, Community,

I need your help with this Jira workflow for software development. I get the concept but have a few doubts about step # 2.

when developer is done with work and functionality is in QA environment, developer moves the issue to QA status to send to QA team to for testing
when QA tester has tested and passed the issue in QA environment, then tester moves the issue to DONE to send to product owner for validation in staging
1. Note: Tester must choose resolution status (because resolving issue at this step in the flow)
when product owner receives issue in staging environment, moves issue from DONE status to User Acceptance Testing status
1. Note: Resolution Status from step 2 remains even though issue is not yet validated and ready for deployment
when product owner rejects the issue in staging environment, moves issue from User Acceptance Testing status to Ready for Development status
1. Note: Resolution Status from step 2 remains even though issue has been rejected and is sent back to developer
Repeat Steps 1, 2 and 3
When product owner accepts the issue in staging environment, moves issue from User Acceptance Testing status to Ready to Deploy status
When technical lead releases functionality to production environment, moves issue from Ready to Deploy status to Production status

My questions and concerns:

Will reporting be accurate to give me true start and end of the issue (i.e., aging report)?
Will sprint report be impacting having multiple DONEs throughout the sprint?
I noticed that the resolution field does not work anymore when using "unresolved" as resolutions state to get open tickets. Will other functionality be impacted due to resolving issues as soon as tester passes them and not when deployed to production?
I also noticed Jira is striking issues through when marked DONE and issues are not yet validated by product owner in staging; and even when issues failed and sent back to developer. Will this confuse Jira when reporting velocity and forecasting?

Comments

Jack Brickey

Hi @Mayte Eme ,

I wonder if having separate issues, possibly subtasks of the main issue, would be better? In other words, you could have the following scenario...

Story - As a user I would like to be able to change the color of the main menu bar

Subtask - Develop...

Subtask - Test

Subtask - Deploy

Any Bugs could be created and linked to the main story. Subtasks could be reopened as needed/desired. The PO could own the progression of the Story.

Mayte Eme

I did some research and came across what you are proposing too. I asked the same question but seems the flow I described is what team is recommending instead. That's why a bit confused and concerned about tracking, reporting and the experience itself.

KJ_dhll5l

Multiple "Done" states IS going to affect your reporting.

Another recommendation is to have a status that indicates it is waiting for product owner's validation - such as Validation. Make it an "In Progress" status category.

You can require a comment or custom field when transitioning to that new status so that the issue wouldn't be resolved - which would also impact reporting.

Mayte Eme

Thanks for the feedback and bring that up to scrum team and agile coaches in out next meeting

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

workflow

best-practice