It's all about the answers!

Ask a question

Sprint burndown chart does not reflect the correct data


Abigail Samuel (1154) | asked Jun 17 '10, 9:20 a.m.
Hi,

We are using RTC 2.0.0.1. We often find that the sprint burndown chart does not reflect the correct hours as shown in the sprint plan.

For example, we are currently half-way through a sprint, and the progress bar of the sprint plan shows 432 hours done out of 828 total hours. However the sprint burndown chart plots the highest point as 511 hours only. Why is there a difference?

Also, what happens if tasks estimated for a certain number of hours are added by different team members on a certain day, but the tasks with an equivalent number of hours are also closed on the same day? As the data snapshot is taken only once every 24 hours, it will not reflect any change on the burndown chart. How can we have the data snapshot taken more frequently?

Regards,
Abigail

4 answers



permanent link
Rafik Jaouani (5.0k16) | answered Jun 17 '10, 10:52 a.m.
JAZZ DEVELOPER
The last point in the burndown chart is live and will show you up to the second up to date data.

The other points are taken in 24 hour intervals. So yes you could miss peeks that happen during the day.

We highly discourage increasing the frequency of the snapshots. In a system with numerous work items, doing so, will for sure impact the performance of your server and will increase the size of your DB significantly.

As for the differences between the Burndown chart and the sprint plan, which do you think is displaying the correct value?

permanent link
Abigail Samuel (1154) | answered Jun 17 '10, 1:47 p.m.
The last point in the burndown chart is live and will show you up to the second up to date data.

The other points are taken in 24 hour intervals. So yes you could miss peeks that happen during the day.

We highly discourage increasing the frequency of the snapshots. In a system with numerous work items, doing so, will for sure impact the performance of your server and will increase the size of your DB significantly.

As for the differences between the Burndown chart and the sprint plan, which do you think is displaying the correct value?


Thanks for the clarification regarding the frequency of snapshots.

The progress bar in the sprint plan displays the correct value (I totaled the hours in the tasks - both estimates and time spent). The difference between the sprint plan and the burndown chart is over 300 hours which is way too much to be only due to the data snapshot taken the previous midnight.

permanent link
James Moody (3.3k24) | answered Jun 25 '10, 1:22 p.m.
JAZZ DEVELOPER
On 6/17/2010 4:38 PM, abisamuel wrote:
rjaouaniwrote:
The last point in the burndown chart is live and will show you up to
the second up to date data.

The other points are taken in 24 hour intervals. So yes you could
miss peeks that happen during the day.

We highly discourage increasing the frequency of the snapshots. In a
system with numerous work items, doing so, will for sure impact the
performance of your server and will increase the size of your DB
significantly.

As for the differences between the Burndown chart and the sprint
plan, which do you think is displaying the correct value?

Thanks for the clarification regarding the frequency of snapshots.

The progress bar in the sprint plan displays the correct value (I
totaled the hours in the tasks - both estimates and time spent). The
difference between the sprint plan and the burndown chart is over 300
hours which is way too much to be only due to the data snapshot taken
the previous midnight.


Could you log a defect in the Reports component with the details and
we'll take a look? Thanks.

james
RTC Reports Team Lead

permanent link
Zachary Smith (6) | answered Jul 02 '14, 1:03 p.m.
Did anything become of this? I am having same issue where 21/67hrs is not 87% complete.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.