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

Answer 2

Usually you will have one team (dev + qa) and one project and track the progress for the team, since in this case a task is NOT regarded DONE until tested and verified.

If your case you want to have two teams - well you may need to have two projects. However, in my opinion, this is not the opimal case. The dev and qu teams should be semantically connected when working on a same project. When the dev team initially finishes developing a task, then it needs to be tested but you cannot be sure that the dev team is done with that task since there may be a bug in the code and the qa team will have to return the task to the dev team and that team will have new work on the task. I am not challenging your management methods, I am rather just saying that this may be diffucilt to measure and maintain.

On when "a task should be considered completed" I don't thing that you'll be able to change this default behaveour, however you can raise an issue with Atlassian themselves: http://support.atlassian.net/.

You can however create separate projects for both teams. For example: ProjectName-Dev & ProjectName-QA. And then when the dev team finishes something create the corresponding task over in the other project. This was you'll be easily tracking the separate teams' progress. However this seems as too much manual work for me. There is another possibility -task can be moved between projects but that may affect the final view of the burndown chart. If you adopt a model that uses a master issue for all tasks (per module or some other piece of work) and then move the subtasks you may be able to keep the "time spent" data.

Go ahead and ask Atlassian. :)