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

Julia Wester [W

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.