Why Does Burndown Show Issue Reopened When Status is Closed?

[John Halbert]

When looking at the burndown chart for issues in the current sprint, several issues were just closed which now increased the remaining values.  The chart says the issue was reopened, when the status is closed.  Why is that?

The board uses a custom workflow, and I just looked at the closed step and the linked status is closed as well.  Is there something else I need to check to make sure everything is configured correctly?

[Jack Brickey]

@John Halbert, welcome to the Community. I would start by looking at the full History of one or more of the issues to better understand the transitions. Unless Reopened is actually a status you have created it may just be telling you it was previously reopened, e.g. To Do > In Progress > Done > To Do (reopened) > Done

[John Halbert]

Thanks for the response.  The red line for the number of issues in the sprint goes up though... shouldn't it go down if the issue is closed?

[Jack Brickey]

fair question. I would have to run some tests to see the behavior firsthand but my tests might not reflect your observations. However, keep in mind that the count in the chart is based on the Resolution field. You need to see what happens when an issue is reopened. The proper behavior is to have the Resolution field cleared when reopening and of course set when closed again. The question in my mind is if you reopen and issue and the resolution is cleared but the "remaining estimate" is zero what does the count do? Increase by original estimate or not increase. I don't know that I have ever tried this or at least thought to look at the burndown impact. Should be a quick test for you to better understand.

[John Halbert]

Thanks for responding again.  I went back and transitioned one of the issues through the workflow.  I noticed that when transitioning an issue from 'Closed' to 'To Do', the burndown report shows it as being moved onto the board from an unmapped status.

I have a feeling this has something to do with what's going on, but I really don't know enough to say what that means.

Just to be thorough - our board has "Waiting for Development", "Being Developed" and "Development Complete".  There is also a "Done" status that's not represented on the board (hence the previous paragraph I assume).  When moving a ticket from "Done" to "Waiting for Development", the issue line on the burndown report is unchanged.  There's an additional event/node recorded there, but the height is unchanged.  Transitioning the issue through "Being Developed" and then into "Development Complete", however, causes the issue line's height to reduce.

Thinking through it I'm guessing the burndown chart is tied to the board, not the sprint.  Is that the correct way to think of it?  Because the workflow is actually split across two boards, and the sprint likewise tracks across both boards. (workflow continues from "Development Complete" to "Waiting for Testing", "Being Tested", "Testing Complete", the testing statuses being mapped to a dedicated QA board.

If what I'm saying is somewhere in the right ballpark, I will say I still find it confusing why moving the ticket to an unmapped status would cause the chart to see it as being re-opened.  So, maybe I'm missing something in there.  I guess for now I understand that I can leave tickets in the "Development Complete" column and expect the burndown chart for that sprint to behave the way I expect.  But, it would be nice to have some idea why the report behaves like that too.  Do you know what else might be coming in to play here?

[Jack Brickey]

ah...so i'm guessing that 'Closed' status is not your right most column. Can you provide a screen shot of your board settings > columns. It would also be useful to have one of your workflow as well. Recall that the right most column is the status that represent the issue is done (resolution set to done) and the burndown is then decremented. So i'm suspicious that your board is ill arranged but just a guess.

[John Halbert]

Right, 'Closed' isn't mapped to any board.  There are two boards, one for development and one for QA.  The workflow spans both boards.

[Jack Brickey]

Ok so the observed behavior is certainly due to the boards configurations. If you move an issue from Closed back to the development board it will be see as sprint churn and increment the count. There are a couple of thoughts I will share here FWIW but keep in mind they are only my opinion based upon my experience w/ agile and the tool. 

• by breaking your workflow across two boards the sprint burndown and agile approach are really not going to work well as designed
• if you need to separate QA from Dev then I would recommend not using the same issue spanning both boards.
• I would suggest using different issues for QA, i.e. "develop feat1" is the development issue and "test feat1" is the testing of the issue. If QA finds a bug they open a bug and it goes in the To Do status into Backlog. You can use different issuetypes if it help keep them separated.
• Simplify the workflow: To Do, In Progress, Done rather than having specific verbiage.
• Avoid reopening issues once Closed. I'm not a fan of reopening issues. Opening a new issue is cleaner. Going back to To Do from In Progress is fine but if an issue is closed it should be final. Again, just an opinion.

BTW, I attempted something very similar to you years ago and in the end really regretted it. 

[Chad Obrien]

John, I am having a similar issue.  We split the boards as well for release and this has worked ok for me before, but yes soon as it goes to unmapped it makes the burndown chart jump.    

Maybe this is intended by Atlassian, but I can't see why myself.

[Samira Negm]

We the same issue and it's very frustrating!

We have separated the deployment in another board but now if an issue moves to shipment in the deployment board, the burndown sees this issue as reopened