What is the JQL used to drive the Release Burndown charts in JIRA Cloud?

[Patrick]

In the Release Burndown, report I'm seeing some odd behavior where there is activity before the project even starts where I can see sprints where 82 points was added to version and said 82 points completed.  I'd like to know the JQL that is used to calculate the number of points so I better understand the Release Burndown chart and how our behaviour affects this.

1. At start of sprint

2. Added to version

3. Completed

4. Remaining

I suspect that the oddness may be because we set things to Done that are not actually worked on, for example Done with a reason of Won't Do but I need to know the JQL to verify that assumption.

[Andy Heinzer]

Hi Patrick,

It's not that there is specific JQL you can use within this report to find that information.  All the reports you see from a board (including this one) are being based on the saved JQL filter that board is using.  So perhaps if your board's filter is adding or eliminating these issues based on their specific status or resolution state, maybe this might do something funky with the way this report is intended to help you understand how your team is progressing towards a release/version.

Are your issues in question here being estimated, placed into sprints, and then marked as completed?  It sounds like this is what is happening even if those issues are not actually being worked on.   In which case, I could see how this would give you a possible perception of more work being completed than was actually done.

I would recommend checking out the documentation on this report if you have not already, please see Release Burndown.  Perhaps this too can help explain better how this report works and in turn might better explain what you see here.

Regards,

Andy

[Patrick]

Sorry, to be more specific what modifications are applied to the board filter JQL to calculate the values used by the Release Burndown chart, notably:

1. At start of sprint

2. Added to version

3. Completed

4. Remaining

My issue is that before the project even started, I see full green bars suggesting that a load of things were added to the project but then set to Done back before any work on the project even started.

[Patrick]

Work on release 19.2 only started in 19.2 Sprint 1.  We don't understand why the Release Burndown has anything attributed to sprints before this date.  The product owner was assigning things to the release and we were estimating it but they were not being assigned to a sprint and work didn't start until 19.2 Sprint 1.

[Andy Heinzer]

Hi Patrick,

Is it possible that your site has renamed version/releases?   I ask because I can see a scenario where issues might be included into an old sprint, but have a 'FixVersion' value to something like 'future release' or 'to be completed later'.

Normally the fix version is left empty if the issue is not clearly going to be resolved in that version, but if say your fixVersion field in your Jira is set to be a required field (just hypothetically), then all issues would have to have a value in that field at all times, even when they are first created.   I don't know if that applies to you here, but if it does, it would certainly cause some strange problems like this.

If that 'future release' then got renamed in Jira to something like 'Version 23', then all those issues of past sprints that used the old version/release name would appear in a report like this.

It might also help to go look at the Sprint Report for one of the past sprints like 18Q4-1.  There is clearly a -13 there.  Perhaps we can look more closely at the completed issues in that sprint and perhaps we can look more closely at the specific issues there to see if we can determine what fixversion/release those 13 story points come from.  I'm suspecting that you had one or more issues that were marked as this fixversion or the fixversion's old name at that time that would explain this behavior.

Andy