Welcome to the FogBugz Knowledge Exchange

Question

0

The Milestone management function allows one to create a tree structure of Milestones. Let's say we have three milestones which are being worked on concurrently by three different developers.

Milestone 1 - Developer 1
Milestone 2 - Developer 2
Milestone 3 - Developer 3

I then start mapping out some future milestones. I want Developer 2 to work on Future Milestone 1, so I set it to be dependent on Milestone 2.

This is where the problem starts. When you look at the Schedule reports, I would expect the estimated completion date of Future Milestone 1 to be (estimated completion date of Milestone 2 + estimated time for Future Milestone 1).

What I actually see is (estimated completion date of Milestone 3 + estimated time for Future Milestone 1). Furthermore if you look at the developer timelines, Developer 2's work on Future Milestone 1 is shown as being blocked by Milestone 3, even though Future Milestone 1 isn't dependent on it.

If you put in completion dates for the milestones in the correct order, it suddenly starts to work again, but it is a bit fiddly to do that and keep it up to date - shouldn't FogBugz be able to figure it out from the milestone dependency graph? Or am I just Doing It Wrong?

flag	asked Jan 4 2011 at 23:55 Matt Hall 1●2

Rich Armstrong · Answer 1 · 2011-02-07 21:05:30Z UTC

2

Two observations here:

Milestones should contain cases by multiple developers. By having one developer per milestone, it's skewing the results.
Milestones are expected to be completed in the order of their date, one after another. Milestone dependencies are really only meant for things like "If the data center doesn't have servers, we can't deploy." Milestone dependencies within the same project should be represented by their date.

answered Feb 7 2011 at 21:05

Rich Armstrong♦♦
13.1k●12●29

	That's interesting - the reason I only had one developer assigned to the tasks was that I was simulating my intended use case with a simple demo project. Can you expand a little on how adding multiple developers into the mix will change the output? As for the dates - thanks, I understand better now how this works. However this seems to be at odds with the elastic nature of EBS - I feel like I would have to be constantly tinkering with the start dates for dependent milestones as a milestone slipped or was completed faster than expected. – Matt Hall Feb 7 2011 at 22:16
	My suggestion over email to Adam for start dates was this: I think that Milestones that don't have an explicit start date should automatically get an estimated start date based on milestone dependencies, developer assignments, and EBS estimates, and the schedule view should use that to do the ordering. – Matt Hall Feb 7 2011 at 22:17

adambox · Answer 2 · 2011-01-06 19:39:21Z UTC

0

It sounds like you might be inadvertently giving EBS information it thinks is important but is not actually relevant to your workflow. Since this is a bit complex, I'm going to shoot you an email to figure it out together. Anyone else interested, I will update here when we have it figured out.

answered Jan 6 2011 at 19:39

adambox♦♦
21k●15●48

	Thanks Adam. I didn't hear from you yet, lmk if your emails have been bouncing. – Matt Hall Jan 19 2011 at 21:07
	Could you send us an email at customer-service@fogcreek.com and mention Case FC1996342? – adambox♦ Jan 20 2011 at 14:07

Weird Schedule reports when using a tree of milestone dependencies

2 Answers