My Release Burndown report for "Release X" is showing a sprint ("Sprint 592") that is made up of issues assigned to "Release Y". It's skewing my report, and rendering it useless. Please help resolve. More information: Sprint 592 * Start date: April 8, 2019 * Close date: April 22, 2019 * All issues resolved during sprint: Yes * Fix_Version for all issues*: Y * Project: J Release Y * Start date: Jan 28, 2019 * Release date: April 22, 2019 * Project: J Release X * Start date: April 22, 2019 * Release date: July 26, 2019 * Project: J *This was confirmed using the following filters: * "Sprint in (592) AND fixVersion = X" * "Sprint in (592) AND fixVersion = Y"

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

The wrong Sprints are showing up in my Release Burndown report

Zane Magnus_2pxjmg

My Release Burndown report for "Release X" is showing a sprint ("Sprint 592") that is made up of issues assigned to "Release Y". It's skewing my report, and rendering it useless. Please help resolve.

More information:

Sprint 592

Start date: April 8, 2019
Close date: April 22, 2019
All issues resolved during sprint: Yes
Fix_Version for all issues*: Y
Project: J

Release Y

Start date: Jan 28, 2019
Release date: April 22, 2019
Project: J

Release X

Start date: April 22, 2019
Release date: July 26, 2019
Project: J

*This was confirmed using the following filters:

"Sprint in (592) AND fixVersion = X"
"Sprint in (592) AND fixVersion = Y"

Accepted answers

Andy Heinzer

Hi Zane,

It sounds like you are reviewing your release burndown report, but are finding unexpected sprints appearing within a specific version/release.

There are a couple of different things that can cause this behavior. First among them is the fact that issues in Jira can have multiple values for the fixVersion field on an issue. It's possible that this sprint in question had one or more issues in both fixVersions, or even if it had a single issue in the fixVersion of X. If that happens, it is expected that this sprint would appear in the release burndown of X.

If that doesn't explain your situation here, I would be interested to learn more about the results you get back from those filters you mentioned:

"Sprint in (592) AND fixVersion = X"
"Sprint in (592) AND fixVersion = Y"

How many issues are returned for each of those JQL searches?

How many issues are returned for the JQL query of: "Sprint in (592)" ?

Please let me know.

Andy

All comments

Andy Heinzer

Hi Zane,

It sounds like you are reviewing your release burndown report, but are finding unexpected sprints appearing within a specific version/release.

If that doesn't explain your situation here, I would be interested to learn more about the results you get back from those filters you mentioned:

"Sprint in (592) AND fixVersion = X"
"Sprint in (592) AND fixVersion = Y"

How many issues are returned for each of those JQL searches?

How many issues are returned for the JQL query of: "Sprint in (592)" ?

Please let me know.

Andy

Zane Magnus_2pxjmg

Hi Andrew,

Thank you for your reply, and for your suggestions. Unfortunately though, the issues persists. I have been able to confirm the follow:

None of the sprints in question have one or more issues in both fixVersions;
And neither of the sprints in question have even a single issue in the fixVersion of X.

And regarding the results that I get back from the above filters:

The number of issues that are returned for "Sprint in (592) AND fixVersion = X" is 0, and for "Sprint in (592) AND fixVersion = Y" is 30.
The number of issues that are returned for the "Sprint in (592)" search is 30.

Thanks again, and let me know if you have any other questions.

Zane

Andy Heinzer

Hi Zane,

Thanks for checking that. In reviewing the documentation on the release burndown chart, I think I may have come across a scenario that could explain this behavior.

Under the section called 'Other functionalities', you can expand the question

If a completed issue is reopened or added/removed from a version, how is it represented?

That expands to contain this explanation:

Issue completed in a sprint, then reopened:

The issue will not be shown in the earlier sprint.

Issue completed in a version, but removed from the version afterwards:

The scope will remain unchanged and the work completed is still shown.

Issue completed in another version or without a version, but later included in the version (shown on the report):

The scope will remain unchanged.

Issue completed in a sprint, but only added to the version afterwards:

The issue will be shown on the report, as if it was always part of the version.

The JQL searches you perform now are showing current information. But these reports can sometimes gather information from the state of that issue at the time of completion or sprint completion. I think that is what happened here. If even one issue was in this unexpected sprint and that sprint was closed when that issue in this version, I believe it would still count that issue in this burndown AND log that sprint along with it.

After the fact that issue could have been changed to either remove it from that sprint or reopen the issue to add that issue to a different sprint. Which could then account for your JQL searches right now.

As for figuring out which issue(s) that might be, well that gets harder to do. I would start by trying to look closer at the sprint report itself to see what issues were in that unexpected sprint. Then see if you can take that list of issues to see if any of them correspond to issues that now have a fixVersion value of Y. If so, then you can try to look more closely at the issue history of that specific issue or issues to see what happened to them such as who made changes to these issues.

Try this and let me know if this helps. If this doesn't help, perhaps we should explore creating a support case to see if our other support teams can take a closer look at your particular Jira site to see if can better understand the cause of this behavior here.

Please let me know.

Andy

Zane Magnus_2pxjmg

Hi Andy,

Thank you very much for uncovering that information. My culprit is most likely "Issue completed in a sprint, then reopened". Fyi, the way our teams manage their issues and versions right now is a bit chaotic (we are improving though), and having this knowledge will help us appreciate even more the importance of taking better care of our processes. Thanks again for all your help.

Regards,

Zane

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-software

sprint

burndown

report

release