-
Type:
Bug
-
Resolution: Support Request
-
Priority:
Medium
-
None
-
Affects Version/s: 6.4.5
-
Component/s: AgileBoard
-
Environment:
Atlassian Cloud
-
6.04
We have an active sprint that when we view the burn down chart shows 70+ hours remaining. When I run a JQL against the spring for remainingEstimate >= 0m and export the results to Excel I see: 19380 (seconds) or 5.38 hours.
The issue appears to be caused by our workflow. When a issue is moved from our QA step (Ready for Testing) to Resolved we have a Transition Post function that sets the remaining estimate to 0m. The burndown chart doesn't seem to recognize that the remaining estimate is 0m.
It seems like the burndown chart is trying to use work log entries to figure out remaining estimate instead of using the actual remaining estimate. I'll be honest we don't always use the work log entry, we should but we have a different time tracking system so most people don't use it when the work doesn't span more than a day.
- relates to
-
JSWSERVER-5681 Editing Remaining Estimate using custom workflow does not cause Greenhopper to update Time Remaining on release
-
- Closed
-