Burndown reports showing different story points than other reports
Platform Notice: Server, Data Center, and Cloud By Request - This article was written for the Atlassian server and data center platforms but may also be useful for Atlassian Cloud customers. If completing instructions in this article would help you, please contact Atlassian Support and mention it.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Fisheye および Crucible は除く
問題
Looking into the Release burndown chart or Epic burndown chart, you may sometimes notice that the Story points reported are different from other reports (like Sprint report or Epic report or Velocity chart).
NOTE : Burndown chart does not seem to reflect the same behaviour.
Looking closer into these reports, you may find that the issue considered as part of the report are different in burndown reports as compared to the rest of the reports.
For example :
My Sprint 1 : Sprint Report
Story points burnt here are 27
Now, we reopened TEST-8 and and closed it outside My Sprint 1. My Sprint 3 was the active Sprint at that time.
So, looking at the reports now,
Release burndown report
Notice that the Story points for My Sprint 1 are now 12 and that for My Sprint 3 are now 15 because it added story points for TEST-8 to Sprint 3.
The Sprint Report remains the same as above > No change there.
This is how discrepancies can be seen in the reports.
ソリューション
The principle behind the burndown reports is different from the one behind the other reports. So, both these reports are looking at the same data set but in a different perspective and hence reporting different numbers.
Both reports are correct and showing the right information as they calculated. So we dont need to change anything here except understand how each report operates.
Burndown reports are calculated as point in time instead of the actual sprints or issues. These reports take into account when issues change and get updated retrospectively.
So, if an issue is closed at a point in time, then in burndown report, it is counted against the sprint that was active at that time. This issue does not have to be associated with that sprint in any way.
For example :
- An issue was associated with a Sprint (say Sprint 1) and closed as part of that Sprint
- Then burndown report will show this issue as part of this sprint.
- Later that issue was reopened and then closed,
- Then burndown report will get updated and this issue will be counted against the Sprint that was active at that time when the issue was closed the second time.
- This could be Sprint 10.
There can be many such cases where the burndown reports information will not match the sprint report.
A Sprint report (and the same with Epic report) is much more straightforward as it looks as the issues that have been part of the sprint at any given point in time.
So, in essence, these 2 reports are looking at the data in the database in different perspectives. This causes them to report different numbers.
There are some examples mentioned in this page as well : Release Burndown report shows total Story Points mismatch.
There are also some bugs that we are tracking on our side that may help with understanding the current situation :
- https://jira.atlassian.com/browse/JSWSERVER-16105 - Burndown Chart Data Corrupted By Multiple Done Transitions
- https://jira.atlassian.com/browse/JSWSERVER-12616 - Agile Boards containing multiple active Sprints lead to inaccurate information in Release Burndown report