Jira Greenhopper Burndown

Question

In my scrum workflow, when a story's development is done, the story is moved to Resolved state and only after QA is done, the story is closed.

Since the QA team is working separately with the dev team, when I'm tracking a dev team progress I'd like the burn-down chart to reflect the team progress so a task should be considered completed in Resolved state and not only in Closed.

Answer 1

I must say that I agree with one element of the previous answer: the optimal setup in Scrum is to have only one team. Unfortunately, in some context you don't have this option. So if it s your case, here is my answer:

First I don't suggest creating separate project. With features in the last versions of JIRA there are plenty of other way to do it. One is to use the Greenhopper plug-in and create two different board on the same project: one for Developer and one for QA. I had the same kind of challenges you are mentioning and here is what we did:

Requirements for this team:

• The definition of DONE for the development team is 'Ready for production'
• The definition of DONE for the QA team is 'Closed'
• Development team are responsible to do their own testing first.
• QA team are into a different time zone
• QA team work with the development team during a Sprint (staging & prerelease test)
• At the end of a Sprint there is often a deployment, so QA team start 'post production' QA.
• Development team on their side already start working onto their next Sprint.

JIRA setup:

1) I've created a custom workflow for my project, taking into account the different "intermediary status" we have between "Resolved" and "Closed". Here is an overview of our workflow:

open -> InProgress -> Resolved -> Staging-> Ready for Prerelease-> Prerelease->Ready for production -> Production -> Closed

2) then I've created a "Development" Scrum Board configured as follow:

3) finally i've created a "QA" Scrum Board on the same project, configured as follow:

Result:

We now have two views of the current Sprint, one for developers and one for QA. Those two views take into account the fact that the definition of done is slightly different for each team.

Development Board

QA Board

We've been running with this setup for about a year now and it still fits the bill :-)

hope it helps