Handling two columns that should count as done in the burndown.

[Tim Clark]

Okay, so in my workflow, I have a column for Ready for Release. It's where QA moves items to when they've finished testing but prior to releasing into production. Our release schedule is very flexible and doesn't always align with the end of the sprint. I have a few problems I had questions about.

First I want the Ready to Release column to count toward an issue being done, just like the done column for my burn down.

Second, when I complete the sprint I still want the Ready for Release column to automatically roll over into my next sprint.

A solution that would allow both of these things to happen would be great.

[Ste Wright · Accepted solution]

Hi @Tim Clark 

What you described above isn't possible natively - Jira classes the last column on a board as "Done". If an issue is in this column, it'll be burnt down but not appear in the next sprint - if it isn't in there, it's not classed as complete and can move to the next sprint.

I would suggest considering what your Definition of Done is - for example:

• Released: If DoD is released, then an issue isn't "done" in Ready for Release. This means you aren't meeting your DoD consistently in sprints, so I would retrospect the cause and look for a solution.
• Tested: If DoD is testing complete, then I would place Ready for Release into the last column. Whether it's released or not is irrelevant to the sprint. This is the approach I take with larger companies who release less frequently (eg. quarterly), as release reporting can be managed via the Release Hub.

If you need to see how many issues you have in Done vs Ready for Release in either case, you could use:

• CFD: Use the Cumulative Flow Diagram - you could limit it based on columns, or create a quick filter to show just issues in these two statuses
• Dashboard: Visualise them on a dashboard, to show issues which are Ready for Release in an Unreleased Version. 
• Custom Report: Create a custom report to show the chart you desire - for example, an app like EazyBI might be able to manage this, or move your data to excel using the official app and build the report in there.

Ste

[Florian]

I think that is a good example of “You can't have your cake and eat it”. 

A possible solution is to actually close the original issue by setting the resolution and create a second issue for testing/deployment. With Automation for Jira this is straight forward. You can also link the new issue to it’s predecessor that way and reopen the original if testing fails. For this you need a testing workflow with two final statuses. “Pass” and “fail”.