The wrong Sprints are showing up in my Release Burndown report

Zane Magnus May 28, 2019

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:

  1. "Sprint in (592) AND fixVersion = X"
  2. "Sprint in (592) AND fixVersion = Y"

1 answer

1 accepted

0 votes
Answer accepted
Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 7, 2019

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:

  1. "Sprint in (592) AND fixVersion = X"
  2. "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 June 11, 2019

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
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 12, 2019

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 June 13, 2019

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

Like # people like this
Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 14, 2019

Hi Zane,

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.

Regards

Andy

Yvonne April 23, 2020

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?

Cheers

Yvonne 

Yvonne April 23, 2020

Sorry, not totally the same case: The completed issues shown in the release are correct and belong there. But the sprint is a wrong one.

Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 23, 2020

Hi Yvonne,

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

Regards,

Andy

Yvonne April 24, 2020

Hi Andy, 

yea, that's it! It's the bug. Thanks a lot for your support - at least I know I haven't done some silly stuff :) 

Best

Yvonne

Like Andy Heinzer likes this

Suggest an answer

Log in or Sign up to answer