It's all about the answers!

Ask a question

Burndown charts show incorrect data


Michael A. (15813) | asked Mar 26 '13, 6:21 a.m.

Hi,

we are currently running 6 scrum teams on our 4.0.0.1 RTC installation.

For some reason, a few burndown charts are incorrect. When I open the burndown chart and hover over the "Remaining work" element, I see 13,7 hours remaining. The plan is displayed for

  • "Team Area": "Our team"
  • "Timeline": All
  • "Interval": "Current Iteration
  • "Details": 2

When I open the taskboard and have a look at the "Load", I see that 36,5 hours are open. And 36,5 is correct. So the burndown chart data appears to be incorrect. But how can that be?

The problem occurs for one team. All of the other burndown charts are just fine.

Does anyone have an idea what's wrong here?

Regards
Michael

2 answers



permanent link
Lauren Hayward Schaefer (3.3k11427) | answered Mar 26 '13, 6:50 a.m.
JAZZ DEVELOPER
Hi Michael,

I believe the burndown reports are not live reports; instead, they use data that was captured when the data collection jobs were run.  I'm wondering if the amount of work remaining changed after the data collection jobs were run.  You can try manually kicking off the data collection jobs and checking if the report corrects itself.

Also, I found this information about the burndown report:
This report plots the remaining backlog of work in terms of the time estimated to complete it. Agile development methodologies such as Scrum use a burndown to plot the daily progress toward the end of a sprint.
Ideally, the chart will show a trend toward zero hours of remaining work as the sprint comes to a close.
Only work items which are open and in progress and which have an estimate specified are included in the calculation.
The blue line indicates the burndown, or remaining work in hours. The grey line indicates planned work, or the sum of the remaining work and the completed work. The "Ideal" line indicates what an ideal iteration would look like with a steady burndown from the beginning to the end of the iteration. The ideal line uses the last data point for planned work as its starting point. The "Expected Complete" line is a forward-looking plot from the current state of the burndown line to the end of the sprint, indicating the required rate of workj if the iteration is to complete successfully.


Comments
Michael A. commented Mar 26 '13, 11:36 a.m.

Hi Lauren,

thank's for your reply. You're right - the data for the Burndown charts is collected regularly. This get's visible when the collector job fails and one data point is missing in the middle. In our environment the job runs at 00:07 a.m.

As far as interpret the charts the charts are resulting from two data sources. On one hand there are the collected data points (for the past) and on the other hand there is the live data from the iteration. This would explain why the last data point is always closer to the previous one.

So far that's all ok.

We are experiencing this strange behaviour that one chart is displaying incorrect data for quite a few days now. The intersting thing is that only one team is having these troubles. The others are correct (as far as I can say). The collector job was running and constantly returning the wrong results.

I'll try kicking off the collector job manually, that's a good idea.

Regards
Michael


permanent link
Kevin Ramer (4.5k6172190) | answered Mar 26 '13, 8:26 a.m.
There are many subtle things that can also affect this chart.  Check the Data section for the Planned Release iteration and the current iteration.  Often the current iteration is taken from some mysterious iteration not even in your project area.   If you have only the default "Main Development" time line, Edit its properties in RTC Eclipse to change the identifier from something other than 'development'.  All project areas created with scrum template will have this default configuration thereby causing confusion regarding the choice of current iteration.

Other things to check:

  • That the time boundaries of your Release iteration include endpoints of all child iterations, plus at least 1 day.
  • Each iteration should have the "Release is Planned" checked

Comments
Michael A. commented Mar 26 '13, 11:43 a.m.

Hi Kevin,

thank's for your reply.

I double checked the current iteration. I even changed the burndown chart parameters from "Current Iteation" to "Sprint 39" (which is the current iteration) - same result. The chart shows exactly the same data.

Thank's for the hint on the "development" iteration. That sounds reasonable to me that this is causing problems. I renamed it. I guess that I'll have to wait for a few days now to see if the data is still wrong or not.

Let's see if this change solved my issue.

I'll let you know.

Regards
Michael

Your answer


Register or to post your answer.