Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

The wrong Sprints are showing up in my Release Burndown report Edited

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 Jun 07, 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

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 Jun 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

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 Jun 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

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 

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 Apr 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

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
TAGS
Community showcase
Published in Jira Software

How to create Jira issus from Excel file?

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...

4,496 views 22 32
Read article

Community Events

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

Events near you