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; } } }

Advice from tracking QA workflows for Scrum teams

Mara Julin

Hi folks, I am wondering what the best practices are for tracking QA handoffs/workflows for Scrum teams.

Like any typical team, our squad pushes changes through several QA handoffs:

- Code review

- Visual qa

- Functional qa

- UAT

Currently these are set up as columns within our scrum board, but I've noticed that oftentimes our changes don't go through these linearly (waterfall), and will often parallelize (specifically vis and func qa). As such, folks don't use the jira board consistently and it can be difficult to understand the status of things.

Is it against best practice to move steps that could be parallelized, like visual qa and functional qa to "sub-tasks"? What are the risks in doing that?

While the workflow makes more sense to me in parallel, I fear we will then lose the visibility into how long each status takes. However, if folks aren't using this linearly anyways, then we don't even have that data.

Thoughts?

Accepted answers

Mark Segall

Hi @Mara Julin - The first question I always ask is whether your sprint flow is designed for these activities to complete within the same sprint as development.

If the answer is yes, then sub-tasks may make sense to give you visibility into the various team members that may work against that story in a given sprint.

If the answer is no, I recommend separate issues for that activity and making use of links. In this scenario, they can still be on the same sprint, but their sprint goals will be unique compared to the dev team. Sub-Tasks would otherwise hold the story hostage until QA is complete.

UAT is an entirely different animal. I try to coordinate a "release sprint" that is devoted to it where team's primary sprint goal is addressing any critical that come out of it and having enough lower priority items in the backlog that they can work on if UAT feedback is light.

All comments

Mark Segall

Hi @Mara Julin - The first question I always ask is whether your sprint flow is designed for these activities to complete within the same sprint as development.

If the answer is yes, then sub-tasks may make sense to give you visibility into the various team members that may work against that story in a given sprint.

Mara Julin

Thank you for this! Yes all of these activities would be expected to be completed within the sprint. They are also attached to the epic or project ticket since we can't launch without it so it wouldn't be an issue if it holds back a story since we can't release anyways.

My concern with going towards subtasks instead of statuses is that ideally I'd like to track how long each one of these steps are taking. I've seen various add-ons or automations about showing time spent based on the QA statuses, and since subtasks follow a different workflow, we wouldn't be able to. Do you have suggestions for that?

Mark Segall

If you're using sub-tasks, you'll want to start with a simplified workflow because you're removing the need for all of the extra steps by having them split out. I typically go with something like To Do >> In Progress >> In Review >> Done.

From here, I would leverage a component or custom field to establish the type of sub-task so you can create filters specifically for QA sub-tasks. Then you can use any number of dashboard gadgets to get you the information you need like Resolution Time to track QA performance.

Mara Julin

Gotcha, okay and thinking through pointing effort. Currently we point Functional QA to understand their capacity for a given week. I understand that you can point in sub-tasks, but it isn't counted in your velocity report. Does it roll-up to the parent task at all?

Yves Riel _Okapya_

Hi @Mara Julin ,

If you are opened to using marketplace apps, I can possibly propose another approach. In order to be completely transparent, we are the maker of the Checklist for Jira server app.

You could alternatively, combine the visual qa and functional qa status together under the qa status. You then use a the checklist app and have it automatically populated with the items Visual qa and Functional qa. Each item can have their individual statuses (in progress, blocked, etc), something like:

checklist qa.pgn.PNG

This way, you can have both activities in parallel. You can even add a Checklist Workflow Validator to ensure that the checklist is completed before allowing the issue to move to the UAT status.

The only drawback would be that it will possible to find how much time the issue was in the QA status but not in each Visual QA and Functional QA state.

Hope that helps,

Welcome!

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

Quick Links

Find more posts tagged with

jira-core

scrum