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.
*This was confirmed using the following filters:
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:
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.
Thank you for your reply, and for your suggestions. Unfortunately though, the issues persists. I have been able to confirm the follow:
And regarding the results that I get back from the above filters:
Thanks again, and let me know if you have any other questions.
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.
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.
Glad to help out here. I totally understand the chaos that can surround versioning and reporting.
If you feel my answer resolved this issue, please click the Accept Answer button next to my answer. This will help other users that might search similar terms to quickly see this question has a solution.
Hi @Andy Heinzer ,
sorry for addressing you directly but I have the same issue as Zane and I can't make out any of the known mistakes. Still all issues that have never seen Sprint x, were not completed outside a sprint or reopened are shown for Sprint x although belonging to sprint Y.
I'm running out of ideas. Can you help?
I'm having some difficulty following what problem you are having here. Is it that your release burndown is showing issues in sprints that you do not expect them to be in? If so, and you're using Jira Software Cloud, then I think you might be affected by this bug JSWCLOUD-16224 : Release/Epic Burndown Report displaying wrong Sprints.
If that's not it, it might help to create a new post here in community detailing what you are seeing OR creating a support request on https://support.atlassian.com/contact
When to use CSV importer When managing your processes in Jira, there are many occasions where you need to create a lot of tasks. Creating them one by one will cost you a lot of time and effort and i...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events