Epic Burndown Report - Starting Sprint

Question

The docs for the "Epic Burndown" report say ...
The first sprint shown is the one that contains the first issue (in the epic) that transitions out of the 'To Do' status, i.e. work is started on the epic.

I have an example that contradicts this.

What else may determine the first sprint shown in the Epic Burndown report??

Andy Heinzer · Answer

Hi Andy,

Sorry if that bug report does not apply to you here.  I am interested to learn more about your environment and your data here.  I'd like to better understand it so I can recreate the behavior you have reported here.  In my testing of this, I found that the first sprint in that report does appear to be the one that had the first issue in the epic to leave that 'to do' status.

I have a bunch of questions for you about this topic:

* Which issue are you expecting was the first in the epic to change that status? 
* Which project/board is this report located in?
* Is there anything more you can tell me about your environment that might be a factor in this unexpected sprint order? 
* Is this happening in your Jira Cloud Dev instance?  ****dev.atlassian.net or is this happening in some other Jira Cloud site?
* Would you grant me permission to let me see this data in Jira up close? (You can just answer either Yes or No to this question.  If you say Yes, I should be able to grant myself site-admin access temporarily to inspect the data here closer)

With your permission, I'll take a closer look at the data there.  Of course I won't look into the data itself without your permission to do so, and we can still try to troubleshoot this either way.

Please let me know.

Andy

Andy Cortwright · Answer

Hi Andy - we've never had work items in multiple active sprints at the same time. I did a reset on all the work items in the epic so that the sprint value was just the sprint in which the item was closed. So, for example, if an item was in sprint 4 and carried over to sprint 5, then finished in sprint 5, I reset the value in bulk edit to the numeric internal value for sprint 5.

That had no impact on the epic burndown chart.

Andy Heinzer · Answer

Hi Andy,

Sorry to hear about this discrepancy.  It sounds very similar to an existing bug we are tracking over in JSWCLOUD-16224.  In that bug report it provides some detailed steps that you could follow in order to reproduce the behavior that I believe you are reporting here.  Please review the steps listed in that bug ticket to reproduce.  I am curious to see if perhaps these are the same steps you might have taken in your environment to produce these results.  If you have different steps, please let me know I am interested in making sure that this bug ticket is the same one that details your problem here.

Unfortunately there does not appear to be a work-around for this bug at this time.  I do recommend watching that bug ticket for updates and voting on this issue to help our development team prioritize such fixes.

Regards,

Andy