Question

They way I've been using FobBugz is to plan out a bunch of releases (usually one every 2 weeks or so). So, for example, you might have the following releases/milestones in the Inbox project:

• Unassigned
• Release 10.1 (due date 15 Jan)
• Release 10.2 (due date 29 Jan)
• Backlog - accepted but not yet scheduled

As change requests come in they generally go into Unassigned.

After each release I usually have a conversation with the major stakeholder (who's not really a coder) concerning priorities and we discuss which of the new change requests we actually want to implement and, specifically, what we want to attack most urgently (in the next release).

During a release cycle, sometimes priorities shift a little, some things get prioritised and some things get bumped out to the next iteration to ensure the release is made on time.

This works well, but if you schedule in some milestones/releases 2 months in advance, by the time you actually start working on the milestone there is already quite a bit of history in the burndown chart (typically an almost horizontal line dating back for months). If you only work on the release for 2 weeks (which is typical in our shop) or 1 week (typical in other shops) then by in large the burndown chart is going to be uninteresting noise... a horizontal line for 2 months and then finally 1-2 weeks of actual work where the burndown chart creeps down towards zero.

There are a couple of ways that this could be avoided.

• One would be for me, before each release, to create a new milestone and transfer over all the stuff from the old one to the new/real one... then delete the old one. This would work but it's not really how I'd like to work with the software.

• A second option would be to have some kind of "Start Date" on the milestone which could perhaps, by default, be when work was first started on one of the cases in the milestone. My thinking is that the burndown chart could only show data from the start date onward.

• A third option, similar to the above, might not be to have any particular field but at least allow the user generating burndown charts/reports to specify a date filter for the report... that way I could (knowing we only started work on that milestone on the 5th Oct) say "only show datapoints from Oct 5 onwards.

Does the above make sense?

Cheers, James

Case FC1963797

Answer 1

Short Version: We have a zoom utility which can work around that problem, but what you said would create a far more precise picture than a zoom button can, and I like precise. To access the zoom utility, just hover your mouse over the burndown chart and you should see it appear on the right.

If you like this idea, please vote up the question (not this answer)!

Long Version: The burndown chart will start tracking the burn as soon as any case in the Milestone has had time charged against it. This also goes for cases which were worked on in a previous milestone and moved into the new one, cases which were worked on in the current milestone then moved, and a combination of the two. In a perfect world, this is fine. In this world, there are drawback to that thinking. There are a few contributing factors which, taken alone, make sense but cause problems when combined:

First is that we are not going to stop you from working on a case. That's part of the frictionless philosophy of FogBugz. That means you could start working on a case in a Milestone which has a start date in the future. But if you have the time to work on it, why should we stop you?

Second is that we're not going to stop you from moving a case to where it belongs for exactly the same reason. Just because you thought you could squeeze that feature into this sprint doesn't mean we're going to hold you to that.

Third is that when you start work on a feature/sprint, you want to see hours burning off of it. So when you start work in a Milestone, you want to see what happened/what's happening... and that desire doesn't change if a case gets moved somewhere. Thus, we don't want to remove any data.

When you put those three ideas together, you can see several edge and corner cases where you end up with nigh-useless data.