Data snapshots end 12/30 for sprint crossing year boundary
We just completed a sprint that crossed the 2008-2009 year boundary.
I reviewed all our burndown charts and it appears data was last collected on December 30. We don't have any data points for December 31 through January 5.
I checked the Tomcat log and didn't notice any errors related to the RepositorySnapshotTask.
Has anyone else noticed this problem with their burndown charts?
Paul Sims
IBM WebSphere Commerce
I reviewed all our burndown charts and it appears data was last collected on December 30. We don't have any data points for December 31 through January 5.
I checked the Tomcat log and didn't notice any errors related to the RepositorySnapshotTask.
Has anyone else noticed this problem with their burndown charts?
Paul Sims
IBM WebSphere Commerce
5 answers
sims wrote:
Hi Paul,
Could you open a defect against the Reports component with as many
details as you think are relevant? We'll take a look.
Thanks,
james
Jazz Reports Team Lead
We just completed a sprint that crossed the 2008-2009 year boundary.
I reviewed all our burndown charts and it appears data was last
collected on December 30. We don't have any data points for December
31 through January 5.
I checked the Tomcat log and didn't notice any errors related to the
RepositorySnapshotTask.
Has anyone else noticed this problem with their burndown charts?
Paul Sims
IBM WebSphere Commerce
Hi Paul,
Could you open a defect against the Reports component with as many
details as you think are relevant? We'll take a look.
Thanks,
james
Jazz Reports Team Lead
I will James, but I thought I'd first ask to see if anyone else has observed this symptom in their burndown reports. It may be a problem unique to my server instance.
Is there anyone out there who also has a sprint that crosses the year boundary? Did your server collect data after midnight on December 31?
Paul Sims
IBM WebSphere Commerce
Is there anyone out there who also has a sprint that crosses the year boundary? Did your server collect data after midnight on December 31?
Paul Sims
IBM WebSphere Commerce
I've noticed a couple of things about the burndown charts:
First, you have to ignore the date scale at the bottom. It's always wrong and dots don't never line up with the date shown at the bottom. This is easily seen if you look at your burndown on Day 2 or 3 of a new sprint. The same date will show up 2 or 3 times along the bottom. So just because a dot in your graph looks like it's for December 31, it probably isn't.
Secondly, the burndown generates around midnight. So if your sprint ends on December 31st, it will only include data up to the end of December 30th. If you make any updates during the day of the 31st, the report will not be run again at January 1, 12:01am. I'm not sure if there's a way to reschedule the warehousing task that generates the reports, but I haven't found one. Ideally, it should be run BEFORE midnight instead of after to ensure that it gets all the data from the last day of the sprint.
First, you have to ignore the date scale at the bottom. It's always wrong and dots don't never line up with the date shown at the bottom. This is easily seen if you look at your burndown on Day 2 or 3 of a new sprint. The same date will show up 2 or 3 times along the bottom. So just because a dot in your graph looks like it's for December 31, it probably isn't.
Secondly, the burndown generates around midnight. So if your sprint ends on December 31st, it will only include data up to the end of December 30th. If you make any updates during the day of the 31st, the report will not be run again at January 1, 12:01am. I'm not sure if there's a way to reschedule the warehousing task that generates the reports, but I haven't found one. Ideally, it should be run BEFORE midnight instead of after to ensure that it gets all the data from the last day of the sprint.