The agile burndown chart uses the issue's Remaining hours field even if the issue is resolved. This makes little sense--if the issue is resolved, then by definition it has 0 remaining time.

This is a big annoyance: the chart becomes wildly inaccurate if we use less or more time than estimated to satisfy issues. This makes a mess of time reporting and is a pointless step since, again, a resolved issue has no remaining work. Otherwise, it shouldn't be resolved.

Further, what if we need to reopen the issue? It would be nice to keep burning against its remaining time instead of having to totally re-estimate because we had to manually force it to 0 time before closing it.

Here's a use case:

Time estimate: 4 hours
User resolves issue: 2.5 hours
Time remaining: 1.5 hours
Issue is re-opened for incomplete fix, and user logs another hour on the same issue. If this works properly, then the report just works.

If we adjust the time remaining either manually or with a post action, then it will have have scope adjustments at Resolve, and then scope adjustments at Reopen and then scope adjustments at Resolved again. We are doing what you suggested now, and it renders the Burndown chart a bloody mess. It's not just a workaround, it's a bad hack with nasty side effects.

This also requires users to type in a lot of information, and to do the data input perfectly (as there is no supported method for fixing mistaken input, see GHS-7773). This is a perfect place for very simple automation. This is likely a 15 minute fix on that report.

Expected behavior: If I resolve an issue, the agile burndown chart should consider the issue as having 0 remaining time regardless of the value of its Remaining hours field.