Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Burndown chart for a project with two boards

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?


1 answer

1 accepted

0 votes
Answer accepted

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,


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

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.

Like Hender Ruiz likes this

Suggest an answer

Log in or Sign up to answer
Site Admin
Community showcase
Published in Jira

Announcing the waitlist for Jira Work Management

Hey there Cloud Community members! We’re excited to give you the first glimpse of the new home for business teams on Jira — Jira Work Management. Jira Work Management is the next generation of J...

868 views 14 20
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you