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

Question

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 · Answer

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

Patrick_h53gda · Answer

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.

Patrick_h53gda · Answer

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.