Negative remaining value on Burndown chart
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. 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.
*Except Fisheye and Crucible
Symptoms
The burndown chart for your Sprint is suddenly showing negative value for the remaining value.
Cause
This problem can be caused in 2 conditions :
By changing the original estimate of the issues after starting the Sprint : When you start a Sprint, the Burndown chart takes into account the original estimate for the issues in the Sprint. This number will be used to plot the burndown chart and is not adjusted if you change the estimate after starting a Sprint. So if you start a Sprint with for example, 10 hours and then start logging time on your issues. At some point you change the estimate to 5 hours, while you have already logged 6 hours to the issue, the remaining estimate will show up as negative on the burndown chart.
By not selecting "Adjust Automatically" while logging work but actually manually changing the remaining estimate : When you log work on an issue, you can select one of the following options :
So if you do not select 'Adjust automatically' and choose to adjust the remaining estimate manually, you can get into a situation with negative remaining estimate as well. For example, you choose to manually set remaining estimate to 0 and then log another 1h after that. This would lead a negative remaining estimate situation.
Workaround
Unfortunately there is no workaround for this as this is expected behavior from the system.
Was this helpful?