keithbarton wrote:

hi,

I'm using 1.0GA release and have (ossiby related) problem with
Burndown charts.

The remaining work at the end of the iteration is non-zero, even
though all items in the iteration have been completed/resolved.

This could be because items were deferred out of the iteration into
the following iteration.

OR it could be related to the problem discussed here.

Would appreciate some help as the Burndown chart doesn't accurately
reflect our progress at all!

Also, any hints on why the x-axis does not match the datapoints in the
burndown chart (and other charts for that matter) would really be
appreciated!

Thanks

Hi Keith,

This is a known issue with the Burndown report. You should CC yourself
on work item 57864, which is tracking the fix for this problem:

https://jazz.net/jazz/web/projects/Jazz%20Project#action=com.ibm.team.workitem.viewWorkItem&id=57864

Regarding the other problem (x-axis not matching the datapoints), this
is a bug in the BIRT charting technology. We are in contact with the
BIRT team and hope to have this issue resolved soon.

Hope this helps.

james
Jazz Reports Team Lead

hi,

I'm using 1.0GA release and have (ossiby related) problem with Burndown charts.

The remaining work at the end of the iteration is non-zero, even though all items in the iteration have been completed/resolved.

This could be because items were deferred out of the iteration into the following iteration.

OR it could be related to the problem discussed here.

Would appreciate some help as the Burndown chart doesn't accurately reflect our progress at all!

Also, any hints on why the x-axis does not match the datapoints in the burndown chart (and other charts for that matter) would really be appreciated!

Thanks

millarde wrote:

There are mistakes in the way the Burndown is currently calculated. I
believe these have been addressed by some recently closed work items.
You'd have to search the items up to figure out if the new and
improved one will ship in the upcoming release (today, I hope) or a
later RC.

That's correct. The intention of the burndown chart was that it should
report the amount of outstanding work (measured in hours) over time.
However there were two errors which caused this not to work exactly as
expected:

1. It reported the sum of the estimate field of all Open or In Progress
work items, but did not subtract the "time spent" field. With the fix to
the report, it now subtracts the time spent from the estimate for all
open and in progress work items.

2. The data warehouse did not collect information for work items for
which an estimate was specified but *no* time spent was yet recorded. So
the result was that the burndown chart would omit these work items
(which probably represent a sizeable chunk). In RC2 we've fixed this
behaviour so that it will collect estimate information even when no time
spent has yet been recorded. It will not retroactively fix past values,
however; the values will be correct going forward. If you really need
the historical data for estimates in the past, we can work with you to
drop and re-create the work items snapshot tables in the data warehouse,
which will re-constitute the history with correct values.

Two other interesting tidbits related to burndown:

1. Because the chart is an aggregation of values (that is, SUM(estimate)
- SUM(time spent)), the behaviour may be unexpected in the case where
time spent exceeds estimate for particular work items. We can't tell
that case in the report, since we're only dealing with the aggregate
data (sum of the estimates, and sum of the time spent). As a concrete
example, work item A specified 8 hours estimated, and 10 hours time
spent, and is still open. Work item B specifies 8 hours estimated, and 6
hours spent. The burndown chart reports 0 hours of work remaining.

2. Work items now also contain a "Corrected estimate" field. Starting in
RC2, the data warehouse will collect this value if it is specified for a
work item, and the (regular) estimate if it is not. So the aggregate
information in the data warehouse takes the corrected estimates into
account, even though the information is not stored separately in its own
column.

All of the fixes we've made so far will ship in the imminent release
(RC2/beta3).

Hope this helps.

james
Jazz Reports Team Lead

There are mistakes in the way the Burndown is currently calculated. I believe these have been addressed by some recently closed work items. You'd have to search the items up to figure out if the new and improved one will ship in the upcoming release (today, I hope) or a later RC.