Burndown chart for a project with two boards

[Hender Ruiz]

I configure a project with two boards, the first board is for development and the second one is for QA purposes, so the project issues (Stories and Bugs) start in the Dev Board and Ends in the QA board.

So the first board has 4 statuses, "To Do", "In Progress", "Code Review", And "Dev Done", this last is configure as a DONE status in my workflow.

When a card reaches the "Dev Done" status automation rules move the card to the QA Board changing the status to "QA Pending".

The Sprint report for the DEV board shows me all cards that reach the "Dev Done" status, but the burndown chart remains as a flat line.

Any idea of how I can use the print report for the first board?

[Bill Sheboy · Accepted solution]

Hi @Hender Ruiz 

The boards and reports seem correct, as your team (dev) is doing part of the work, calling it "done", and then re-opening the work for the other team (QA).  So the clock resets.

There are a few approaches to solve this as the teams have decided to split completing work into two stages, both are needed to deliver value to your customers...

• You could use one scrum board, have people doing dev and QA collaborate to finish what is possible within a sprint timeframe
• You could keep what you have for boards, except change the automation to clone the dev-done stories for use on the QA board.  Each would then have separate reporting and work item tracking, but each feature would have two stories: dev and QA
• You could switch to a Kanban board to more accurately reflect how the work flows, with two teams participating one one board's workflow to deliver value

Best regards,

Bill

[Hender Ruiz]

I like the second approach, but how could I manage when QA returns any issue to DEV board? 

[Bill Sheboy]

Hi!  This is a workflow issue, impacted by how your team normally works with defects...

1. Some teams definition of done says a work item is not "done, done, done" until it is tested and in prod, so there are no defects; just one parent work item in Jira.
2. Some teams create separate defects (either independent or as sub-type issues linked to the original), and decide what to do with them based upon severity, impact, and whether or not the defect will be fixed.
3. Others re-open original items when defects are found.  This can be problematic for lots of reasons, including altering histories, hiding the total effort to build features, etc.
4. And so forth...

I recommend "taking it to the teams...": Today, what happens to a QA work item when a defect is found?  If you currently do one of the above, you probably can use automation to handle it, such as re-open the linked dev issue, or at least notify the assignee that a defect was found.