Problem

      Burndown charts rely on an issue to indicate when the chart data began. For example, the Epic Burndown chart will mark the first issue added as the starting point. All issue data/work after this "First Issue" will be considered as part of the Epic Burndown chart.

      If the first ticket is transitioned from a "Done" status to another "Done" status, the Burndown chart will then believe it's part of the latest Active Sprint, suddenly ignoring all data before the active Sprint.

      Steps to Reproduce
      1. Create an Agile project using the sample scrum data
        • You'll notice that the sample data will create 2 sprints: Sample Sprint 1 and Sample Sprint 2
        • Sample Sprint 1 is already completed.
        • Sample Sprint 2 is currently active.
      2. Create a new Epic for the board. Like "Epic1"
      3. JQL search for:
        Sprint = "Sample Sprint 1" and status = "Done"
        
        • These are the "Done" tickets in the first Sprint
      4. Edit this ticket to put it into "Epic1"
        • For our example, let's say this is SSP-23
      5. Now, add a "Done" ticket into "Epic1" from "Sample Sprint 2"
        • For our example, let's say this is SSP-15
      6. View the Epic Burndown Chart
        • Notice how the chart shows data from both Sample Sprint 1 and Sample Sprint 2
      7. Now, open up SSP-23 and click on the "Done" transition again.
      8. View the Epic Burndown Chart
        • Notice that Sample Sprint 1 is no longer shown on the chart
        • Notice the issue list, SSP-23 is shown to be part of Sample Sprint 2
        • If you view SSP-23, the issue view will still show Sample Sprint 1
      User Expectation

      There was no actual change to the SSP-23's field values (sprint, resolution, or resolution date) and no work was done as all estimates have already been burned down. We would expect no change in the burndown chart.

      Actual Result

      The burndown chart is different, no longer showing that "Sample Sprint 1" exists. Instead it now shows SSP-23 as part of "Sample Sprint 2".

      • If you view SSP-23 ticket, it shows that it is part of "Sample Sprint 1", so the burndown chart is not showing actual Sprint data.
      Cause

      When a ticket is transitioned to a status that sets the resolution, the burndown charts are assuming that the ticket is now part of the latest Sprint.

      Extra Notes

      The above example is for the Epic Burndown, but this can happen for the Release Burndown as well.

        1. After transition.png
          After transition.png
          249 kB
        2. Before Transition.png
          Before Transition.png
          258 kB
        3. Done ticket transition.png
          Done ticket transition.png
          240 kB

            [JSWSERVER-16105] Burndown Chart Data Corrupted By Multiple Done Transitions

            kamiln added a comment - - edited

            I think there is a problem with how this report classifies issues. I see issues completed under one sprint that were never a part of this sprint, but instead were closed with "invalid" resolution by Product Owner at the time that sprint was active. So instead of grouping issues by actual sprint they belonged to, they're distributed based on the modification date when the issue was closed? Isn't that going to cause big mess, because outside of sprint issues are often transitioned, and this shouldn't cause inclusion in a sprint that was active at that time?

            kamiln added a comment - - edited I think there is a problem with how this report classifies issues. I see issues completed under one sprint that were never a part of this sprint, but instead were closed with "invalid" resolution by Product Owner at the time that sprint was active. So instead of grouping issues by actual sprint they belonged to, they're distributed based on the modification date when the issue was closed? Isn't that going to cause big mess, because outside of sprint issues are often transitioned, and this shouldn't cause inclusion in a sprint that was active at that time?

              Unassigned Unassigned
              dchan David Chan
              Affected customers:
              13 This affects my team
              Watchers:
              16 Start watching this issue

                Created:
                Updated: