Parallel Sprints or a Dashboard?

[Jenn Molyneaux]

Hey everyone! Let me first give you some context regarding my use case. I'm hoping someone here might have a creative solution to my situation. 

Our QA Manager has their own project in Jira, 'QA'. (As an aside, I did not have a hand in creating this project or the filter it uses; all of this was configured by our QA Manager). 

They want to have a view that shows all of the Issues (across all projects) that enter a QA status as well as all of the work that is happening in the QA project. To do this, they created a filter that returns any Issue (across all projects) that has a status = 'QA' as well as any Issue that belongs to the QA project and applied that to their own Sprint board.

Based on the filter that they've created, issues from other projects appear in the QA Backlog and as a result, they are unable to start their own Sprint in the QA project (since Sprints for other projects are already in progress). They asked me about Parallel Sprints feature and as someone coming from a very old version of Jira Server, this is new territory for me. 

I've been reading about Parallel Sprints and I really like the concept, but from what I read (https://support.atlassian.com/jira-software-cloud/docs/use-parallel-sprints/), the Velocity Chart will no longer work for teams that have sprints running in parallel. I really do not want to lose access to Velocity Charts for all of my teams - those are really important to us. Since they are looking at Issues across all projects, this would impact every team that has an Issue enter a QA status. 

I thought that maybe a Dashboard would achieve what our QA Manager is looking to do. Do any of you have any other thoughts on a better approach? If a Dashboard is the right play, let me know that too. 

Many thanks!!

[Fabian Lim]

Hi @Jenn Molyneaux

Couple of questions: 

1.  What is the complete workflow of the stories/tasks?
2. Just to clarify, the scrum team will start working on the story and add it to their own sprint and at some point, they move it to qa status. Then the qa team picks up the same story and adds it to their own sprint? Doing this would change the scope of the orignal scrum sprint.
3. Does the dev team follow the same schedule as qa? Sounds to me that they would start planning a sprint after a ticket goes to qa status
4. My suggestion would be to create new linked tasks in the qa project to the original tickets that would track the qa work. You can then use automation to update the original ticket's status once that task is complete. This way you can keep your own sprint for only qa tasks without affecting other scrum boards.

I hope this helps.

[Jenn Molyneaux]

Hey @Fabian Lim :)

I'm going to answer your second question first because I think that's a really important part of this whole thing.

Using the Blue team as an example... they have a project 'Blue' and when a story hits the QA status, their QA is working on it in the Blue project; It does not move to the QA project. 

That being said, do your other questions still apply? I'm happy to answer but I wasn't sure if they'd still apply based on the explanation above. 

[Fabian Lim]

Hi @Jenn Molyneaux, 

Does the QA manager want to have a sprint board within the blue project or a central one that picks up various projects? 

[Jenn Molyneaux]

They want to have a sprint board that picks up all of the projects but that also allows them to manage their own sprint work that belongs to the QA project. 

[Fabian Lim]

Bringing stories that are in another sprint board the qa sprint can csuse issues when you assign them to another sprint board.

I will go with my reco 4 and have a dashboard that shows all tickets in qa status status so you can plan the qa work.