This is expected behaviour and in my view not a bug. Let me explain why this is the case.
This behaviour applies to the burndown insight and burndown report, and is consistent.
Essentially, burndown needs to track whether an issue is Done or Not Done.
- When an issue is Not Done the points show in the chart
- When an issue is Done the points are removed from the chart (the line moves down)
Done/Not Done are determined by the status to column mapping, right most column is Done, everything else is Not Done.
So when a status is unmapped, essentially we cannot determine if it is Done or Not Done. We therefore "exclude" it from the Burndown entirely which from a users perspective will look like it is "Done", because excluding it means we remove the story points (or estimation).
The workaround or rather permanent solution is to just ensure that all columns are mapped. If it is intentional that certain statuses are unmapped, these issues are excluded from the board/backlog so it seems logical to also exclude them from insights.
Mapping the statuses will fix both the report and insight. However any issues that were in an unmapped status, when the sprint was started will cause problems with the insight. This problem will only persist for one sprint however, as once corrected and a new sprint started the problem will no longer appear. There is a separate bug for this https://jira.atlassian.com/browse/JSWCLOUD-27063.
Update: Apologies if this is the same bug as the new one, the description is quite ambiguous but we will address this under JSWCLOUD-27063. The existing but doesn't mention anything about mapping an unmapped status though which is when the problem occurs.
Bug
High
This is expected behaviour and in my view not a bug. Let me explain why this is the case.
This behaviour applies to the burndown insight and burndown report, and is consistent.
Essentially, burndown needs to track whether an issue is Done or Not Done.
Done/Not Done are determined by the status to column mapping, right most column is Done, everything else is Not Done.
So when a status is unmapped, essentially we cannot determine if it is Done or Not Done. We therefore "exclude" it from the Burndown entirely which from a users perspective will look like it is "Done", because excluding it means we remove the story points (or estimation).
The workaround or rather permanent solution is to just ensure that all columns are mapped. If it is intentional that certain statuses are unmapped, these issues are excluded from the board/backlog so it seems logical to also exclude them from insights.
Mapping the statuses will fix both the report and insight. However any issues that were in an unmapped status, when the sprint was started will cause problems with the insight. This problem will only persist for one sprint however, as once corrected and a new sprint started the problem will no longer appear. There is a separate bug for this https://jira.atlassian.com/browse/JSWCLOUD-27063.
Update: Apologies if this is the same bug as the new one, the description is quite ambiguous but we will address this under JSWCLOUD-27063. The existing but doesn't mention anything about mapping an unmapped status though which is when the problem occurs.