-
Bug
-
Resolution: Unresolved
-
High (View bug fix roadmap)
-
None
-
7.2.9, 8.21.0, 10.3.5
-
7.02
-
29
-
Severity 2 - Major
-
116
-
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
- 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.
- Create a new Epic for the board. Like "Epic1"
- JQL search for:
Sprint = "Sample Sprint 1" and status = "Done"
- These are the "Done" tickets in the first Sprint
- Edit this ticket to put it into "Epic1"
- For our example, let's say this is SSP-23
- Now, add a "Done" ticket into "Epic1" from "Sample Sprint 2"
- For our example, let's say this is SSP-15
- View the Epic Burndown Chart
- Now, open up SSP-23 and click on the "Done" transition again.
- 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.
- relates to
-
JSWSERVER-15118 Epic Burndown to consider Sprint value of a Story
- Closed
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?