Welcome to the FogBugz Knowledge Exchange

Question

4

The start date for my milestone is 4/1/2010, yet my burndown chart is showing activity from way back in 2009?

What's going on?!

edited Apr 20 2010 at 15:51

asked Apr 20 2010 at 15:40

Rob Sobers
5,245●5●17

1

I find this annoying as well - if I set a start date for a milestone then it shouldn't prevent work happening before that date, but the burndown chart should not show any information before my start date. – Steve Baxter May 6 2010 at 11:55

Was about to create a similar question, and then found this one. Is it correct that there is no way to force the Burn Down Chart to show values from a specific date and forward (it seems to ignore the milestone start date)? My challenge is that I have a milestone where the first few days show alot of erractic numbers while the milestone was being established within Fogbugz and further more a single entry months before the start date, and I would like to "filter" those data out. – HenrikMøller Aug 16 2010 at 13:00

Find this "feature" extremely annoying. We're planning milestones a week sometimes two upfront. The looong tail of zero work is wasting space in the chart, and the week of actual work at the end gets zoomed out to much. Zooming in is not very useful since it will zoom the chart both horizontally and vertically, requiring a lot of scrolling just to see that last week with interesting data. – Peter Apr 29 2011 at 15:17

GollyJer · Answer 1 · 2010-04-20 17:05:54Z UTC

The current algorithm uses the first date any case in the milestone was worked on. As described in your answer, this can cause weirdness with the burndown chart. Maybe the burndown charts first data point should be the start date as defined by the milestone but show time burned up to that point.

i.e. - Day 0 has two points with a vertical line connecting them. The top point is the original time remaining. The bottom point is the time remaining after burning hours worked before the milestone officially started. On Day 1 the chart begins its burn from the bottom Day 0 point. Obviously there would need to be some visual indicator that that Day 0 has some "pre-burn". :-)

Rob Sobers · Answer 2 · 2010-04-20 15:50:19Z UTC

After looking in the ShipDate table for records that reference the ixFixFor in question, I found that someone had created a case and performed work prior to the milestone's start date. The case has since been moved to another milestone, which made it even harder to track down what was going on.

FogBugz didn't stop anyone from doing performing work on the milestone prior to its start date, and now that I think about it, I think that's okay. We want minimal friction. If I'm free and able to start on a milestone early, why block this?

There is still an element of confusion here. Perhaps there's something that can be added to the burndown chart to make the above scenario clear.

JH · Answer 3 · 2010-05-06 12:19:26Z UTC

Given the information in the above answers, one interim proposal would be to add a vertical line to the graph for the start date, in the style of the vertical line for the completion date. At least then people viewing the chart could mentally ignore anything before the start date, and you wouldn't have to change the agorithm too much.

We're suffering quite a bit from the visual "messy preamble" to the start of the burndown chart. We have some cases added / worked on over a long time, and for example in a current milestone there was a case raised in 2007 which had some analysis time logged against it earlier this year. The "messy preamble" on the front of the chart is longer in weeks than the sprint is due to last. So the burn down chart looks like a "burn up" chart, with a sharp drop off at the end representing the actual sprint. I've asked around and we've no one here interested in anything appearing on a burn down chart before the start date of the milestone.

Why does my burndown chart show activity prior to the milestone start date?

3 Answers