Different Scrum Board for Different Part of a Workflow in JIRA Agile

[Tim Yeung]

In my company, our workflow of a development task is as follows:

• Open > Development in Progress > Resolved > Testing in Progress > Closed

For an issue, e.g. bug, developers are responsible to transistion an issue from Open to Resolved. Then, QA are responsible to transistion issue from Resovled to Closed after testing.

So my intention is to setup 2 Agile Scrum Boards, one for the development team, another one for the QA team as follows:

• Developer board
• JQL: project in (TEST) ORDER BY Rank ASC
• Columns: "To Do" Open, "In Progress" Development in Progress, "Done" Resolved
• QA board
• JQL: project in (TEST) ORDER BY Rank ASC
• Columns: "To Do" Resolved, "In Progress" Testing in Progress, "Done" Closed

Above doesn't work, because if there is an active QA sprint, DEV will not be able to start a sprint, because JIRA Agile only allow 1 active sprint in a board by default. When parallel sprint is enabled, it doesn't look nice, because in DEV work mode, issues in QA sprint which are Resolved appears in DEV sprint.

I have also tried the following:

• Developer board
• JQL: project in (TEST) and resolution is EMPTY ORDER BY Rank ASC
• Columns: "To Do" Open, "In Progress" Development in Progress, "Done" Resolved
• QA board
• JQL: project in (TEST) and resolution is not EMPTY ORDER BY Rank ASC
• Columns: "To Do" Resolved, "In Progress" Testing in Progress, "Done" Closed

Above doesn't work because after an issue has a resoltion after Resolve, the DEV board report mode will return an error because issue previously in the sprint filter (resolution is EMPTY) are not inside the sprint filter anymore (as during resolve, a resolution is filled in)

This is really a blocker for our comapny to use JIRA Agile.

Are there any solutions availabe? (The use case where an issue involves both the developer team and QA team makes sense to me...and developer team and QA team having a separate board also makes sense to me...because developer estimate an issue base on development effort and QA estimate an issue base on the testing effort

[Shannon Davis]

We actually do this.  Our Development Team wanted their sprint statistics to reflect completed development work, and there is generally a delay in the QA process because while they test directly in Development, they also wait until everything is deployed to QA, and then test again in production.  Our QA team uses a 'Kanban' board and they pull the work through different levels/environments of testing that are reflected in our process.

I've never had to add "resolution is not empty" to my queries.  I believe you could remove that and your boards would work.

[Ridham Sharma]

Hi Shannon 

I recently started using this approach (seperate boards for Dev & QA), scrum for Dev and Kanban for QA. Although if  issue is still in progress in QA board and I close Dev sprint, issue disappears. Any thoughts  on how to make this work ? I want issues to rollover to next sprint if they have not reached their final status. 

[Shannon Davis]

If the item got all the way to QA Testing, and that's the "last stage" of your process, then it will not be rolled over to the next sprint when the sprint is closed. 

On the other hand, if QA failed the item and it went back to "To Do" or "Ready for Dev" or whatever you call the first stage of your workflow, then you could include it on your next sprint (but jira wouldn't do that automatically).

So, what we do is the Development Sprints are based on the workflow from "Ready for Dev" to "In Dev" to "Ready for Testing" as the last column.  For the purposes of the sprint/scrum  board, that is considered "done".

The QA board starts at Ready for Testing and finishes at Ready For Release (for their purposes, that is done).

So the Scrum Board and the Kanban Board do not overlap except the first stage of the QA board is the last stage of the Scrum Board. 

You  may have to fool around with it a bit to get it the way you want. IT's hard to share my exact process because my workflow is probably quite different from yours.

[Julia Wester [Wittified]]

From a purely agile perspective (not the tool perspective which is what I know you're asking about), the best thing would be to not divide into separate sprints and boards by functional teams/workflow state, but to have a cross-functional view - a single sprint and board, especially if both teams are working on the same work (versus one having a subset of the others' work). Have the story points equal the combined complexity for both people to accomplish what is needed. Have a QA workflow state if you'd like to easily visualize what is being handled by the QA people at any given time. You can put a queue state in between if you'd like to have a pull system for the QA team rather than pushing work into QA when Dev is "done" (although Dev isn't really done until it passes QA).

From the tool perspective, your method throws up red flags to me. It seems like you're trying to get the tool to do something that's not natural rather than looking at how the tool expects things to work and update your workflow to accommodate. This is a common problem across all tools. I know I've done it a time or three.

If you're dead set on having separate boards and sprints within the same project, perhaps the better way would be to spawn a NEW issue for the QA team (via workflow transitions – maybe a separate issue type) if you want to have them function as a separate team. https://marketplace.atlassian.com/plugins/org.swift.jira.cot and https://marketplace.atlassian.com/plugins/net.customware.jira.utils.customware-jira-utilities may be helpful plugins for this.

I'll consider this more to see if I have better ideas.

[Breen Liblong]

W also have a similar issue, and have a separate QA team, with an overlapping sprint period. Dev sprints to dev complete are 3 weeks, QA sprints to release are a week and a half later than the corresponding dev sprint. In our case we have separate dev, qa, and release branches for code, with separate build processes, so it's natural to complete development, and then pull across into the qa branch for subsequent issue testing before moving to the release branch for package (staging) testing and deploy. Some issues are not released to production for several sprints, but are released to integration test servers accessed by partners, before signoff and deployment to production. For this reason, I'm thinking of using a Kanban style board for QA, once dev is complete (including dev testing, code and SQL reviews, before pushing to a Ready for QA status). I've seen various other postings in the JIRA fora where the "solution" proposed was to launch a NEW issue for the team. This is not workable, as it effectively doubles the number of issues, and makes it more difficult to track from beginning to end.