Suggest on managing parallel sprint

[Ramya Yarru]

Hello Team,

I have a scrum project wherein we have 2 teams (Dev and QA) using the same issues where if suppose we create a sprint 1 and have issues assigned, development team would work on it, move it to Done and would close out the sprint and later QA team would do testing on same issues and then move it to UAT which is considered done for them so the issues would appears in backlog again and the issues in backlog would go on increasing and I would want to avoid it.

Please suggest for a better workflow.

[Trudy Claspill · Accepted solution]

Best practice is that a story would not be considered done until both development and QA activities are completed. But if you have a business need to be able to track development work and QA work separately, then another idea to consider is tracking the work of the teams as separate stories. When the development team moves a story to Done that leads to the creation of a new story for QA that moves through the process separately from the development story. You could link the QA story to the development story. You could use Components or Labels on the two stories and either use two separate boards so that the backlogs are separated or use Quick Filters in one board to enable you to focus on only the development or only the QA stories.

[Andy Creech]

I have the exact same issue. 

As a business, the QA team is a shared resource across multiple teams/projects. So they are often in a situation where they are balancing work across multiple projects and cannot be dedicated to single sprint for their work. 

We have tried using multiple tickets to manage the Dev and then QA work, and it becomes confusing to communicate between the dev and QA team what needs to be worked on. We are trying to streamline and remove the separate tickets, but preserve having Dev and QA sprints separate to allow for capacity planning and tracking. 

[Bill Sheboy]

Hi @Ramya Yarru 

The approach you describe will certainly impact Jira workflow and reporting, because issues would be repeatedly started, completed, restarted, etc.

As you note the team(s) are using scrum, have you considered instead:

• Have one scrum board for the team (people doing development and QA to deliver value)
• Only plan/bring in what can be fully completed in the sprint timeframe
• If work doesn't finish within the sprint timeframe, pause to consider why and improve in the future

If you still feel these are independent teams, consider using Kanban instead.  You could still use one board, and would not use the concept of a "sprint", but instead pull work as capacity is available for each step in your workflow.  The advantadge of this approach is much better visibility to team capacity balance (by skill areas) and the duration to complete work fully.

Best regards,

Bill