Hi Jeroen,

I fear the screenshot is misleading. We (meaning I, I am ashamed to admit) couldn’t come up with a way to calculate the remaining hours in a manner that is fast enough. The old backlog implementation would return the remaining hours, but it was faulty. The main problem is summing up only those remaining hours that are not already the sum of their child work packages. So in a package tree of

a(6)

|
| <child>
|
b(6)

we would only want to count the remaining hours of b (6 in this example) and not those of a. That is because a’s remaining hours are only the result of summing up the remaining hours of it’s children. That would be very easy to calculate if it weren’t for the fact that the tree might change over the course of the sprint. So on day 1 we might have a structure like this:

a(6)       b(6)

where a and b are both root nodes of their own package tree. On day one the remaining hours should be 12. But on the next day the tree is changed to the first example and the remaining hours should then only be 6.

Because we are currently not versioning the package tree information, and I am not aware of a way in which it would be feasible to do so, we can not distinguish between the first and the second fast enough for every day of the sprint.

My idea of how to do it nevertheless, is to have some kind of background job that calculates the remaining hours whenever the tree structure or the remaining hours are changed. The result of each day would be cached and presented to the user when he opens the burndown. When changes to the tree structure or the remaining hours happen two times a day, we only keep the newer result.

That would be a way to address this issue but it would be very time consuming to program that and I just haven’t gotten to it. But I am willing to listen to different ideas that might be easier to realise.

Kind regards

Jens