Done status not working on Burndown / Burnup report

[Kiril Tsankov]

Greetings,

I am using JIRA next-gen to manage a scrum project.

I have configured my board as follows with two available "Done Status" columns.

I expect when I move issues to any done status column - that action to be reflected in the Burndown or Burnup report. However, this is not the case. Only the issues which I move to the Done column are reflected in those reports. The result is a very sad Burndown chart at the end of a Sprint :( :D 

So far I have found the following information on the topic which suggests I should be correct but it doesn't seem so:

https://community.atlassian.com/t5/Jira-Software-questions/Wrong-decrement-in-Burndown-chart-Why/qaq-p/1766381

Any insight is highly appreciated! 

[Alexis Robert]

Hi @Kiril Tsankov , 

this is because Jira considers an issue "Done" only when it's moved to the column that's further to the right of the board.

Since you column "For production" is not the furthest to the right, issues in it are not considered done. There is no workaround for this, so you'll need to keep this in mind.

Let me know if this helps, 

--Alexis

[Kiril Tsankov]

Hi Alexis,

Thank you for your input!

In that case, what is the "Done Status" in the workflow configurator used for? Are you sure it has nothing to do with the burndown chart and we're not facing a bug?

- Kiril

[Nic Brough -Adaptavist-]

The status in workflows is an indicator of where an issue is in your process.  

The boards try to show you your process, based on those status, but you have to map the status into the columns (the default is a simple 1:1 mapping of column to status).

The status of an issue does not tell a board whether an issue is done or not, directly.  What matters to a board is the "done" column (rightmost one).  It's up to us humans to tell Jira which status belong in the "done" column.  That's the indirect link between status and burndown - you have to get your "done" status in the right place for Jira to match it to what it sees as "done".

[Rob Wetzeler]

Instead of an assumption on rightmost column, it would be preferable to have the report configurable to pick the column.  In the example above - for production with the status of Done should be an available option to use in the charts.  Right most column is an implied convention that doesn't work for all workflows.  

[Kiril Tsankov]

It would be more convenient and flexible if we could configure any column as Done, indeed.

[Nic Brough -Adaptavist-]

I can see an argument for "the X-most right hand columns", but there's a strong argument that as a scrum team, you really don't care exactly what the status is if the issue is matching the definition of done.  Hence I don't think Atlassian are going to change the last-column thing.

[Kiril Tsankov]

The question was related to velocity reporting. As a SCRUM team, it's important for us to be able to track velocity in the described way.

[Nic Brough -Adaptavist-]

Yep, that's what the last column is for - you burn down and get your velocity measure from the "done" column.

[Kiril Tsankov]

In my case, it doesn't really work great.

We are a small team and pushing to production is not yet automated. Therefore we have some work to be done after acceptance criteria have been met on an issue. On the business side, it sometimes takes weeks before we get approval for pushing items to production. You can imagine what this does to velocity reporting.

Therefore now we have eliminated our For Production column, originally mentioned in this post so we can use the velocity reporting.

We are using releases as a workaround but it's not great since it's extra overhead to configure them.

[Rob Wetzeler]

We are assuming a column and "state", to do, doing, done are the same thing.  In many workflows they aren't.  In fact Jira lets you have multiple workflow steps marked as a Done state.  It's confusing to have both.  If Done is only allowed in last column from a reporting standpoint, then you shouldn't be able to have more than one workflow step a "done" step. 

In our case, our scrum team is "done" but we have workflow steps on a board for our release team.  With rightmost column restriction, it prevents us from using Jira's charts and have to look elsewhere.  For example, post deployment we do QA regression tests on our Jira Issues... so we have our rightmost column for this.  Done for scrum is before this - development complete.  We use Jira to help us coordinate and know what is fully tested.  Yes there are other ways of doing this but its how the team has decided to do it so they can stay on the same page.  They prefer a column to indicate this as a workflow step with the State of Done in each column.  Again the workflow allows for this but then our burndown chart doesn't work until post-release steps have occurred. 

[Nic Brough -Adaptavist-]

I understand both of those, but have a think about how scrum works - your board represents things your team has committed to deliver in a timebox (sprint) and your progress against it.   It's not supposed to show things your team are not responsible for.

In these scenarios, you have added status that do not represent things your team is responsible for delivering.  So you're not using the board for Scrum any more, you've got a different process that isn't suitable for using a Scrum board for, and your velocity is not measuring your team velocity at all.

In this case, I'd go back to having the team do scrum - either put your post-done status into the "done" column, or remove them completely if the issues are never going to reach that status before the end of each sprint.

Then use a second, Kanban board for tracking the overall process.

[Kiril Tsankov]

There is some value to your argument about segregating the dev and deployment teams. In my case that would be virtual segregation, since it's in fact the same developers doing both.

A virtual separation seems nice, but that means having two separate planning meetings with the same people or switching between boards in the same meeting.

A second kanban board. Isn't that a bit of configuration though? I thought about it before implementing the 'Release' practice and migrating the issues to a new board is a heavy overkill if you have to align them with epics again. On the other hand, creating new issues on that board is sort of strange since all the information is related to the original issues, and again, moving it is a heavy overhead.

[Rob Wetzeler]

Fully agree!

[Nic Brough -Adaptavist-]

>A second kanban board. Isn't that a bit of configuration though?

Yes.

But there's no "create on another board" - boards are not containers for issues, they are a view.  For a second board, you tell it to look at the same issues

[dew]

@Nic Brough -Adaptavist- @Rob Wetzeler  @Alexis Robert  please help me, i have the same issue

can you simplyfy to solve my issue? my posting 

[Nic Brough -Adaptavist-]

Yep, map all your "done" status into the last column on the board!

[Simon Hedges]

Doesn't work for me.  My "Done" and "UAT" status (which are both of type "Done") are both in the right hand column on my Board, but the burn down chart on the board does not show "UAT" tickets as burned down - it waits for them to be in the "Done" status.  I am using Jira Server.

[Nic Brough -Adaptavist-]

Can you show us

• the board settings (just for the last column)
• an issue that is not in the column while having the UAT status, including status, resolution, and the sub-task panel 
• your burn-down chart
• the filter for your board (in boards that don't look to a filter, this will be "project = XYZ")  Plain text here, it's quicker than a screenshot.

On the issue view, we don't need most of it, so feel free to obscure most of it, we really do only need status, resolution, the estimation field (story points, time estimate or whatever else the board might be using), and to know the same for any sub-tasks the issue may have.