Question

Hi there.

Just started to use fogbugz in our organization.

Our dev team (5 programmers, flash dev, designer, html coder) works on many different projects simultaneously (in order of priority).

Currently, i've created one global milestone named "In development" (ala current sprint in SCRUM).

What i'd like to do, is to create per-project milestones to use EBS for realistic per project due dates.

But it seems to me (after doing some tests) that when i look at per-project report the EBS assumes that people will only do tasks of selected projects, even if they are assigned higher priority tasks in otherprojects.

Am i right? How this is supposed to work (how can i predict per project due dates for a team working on many projects in order of global priority)?

A later edit:

Okay, i've conducted more tests and i believe i found a bug in EBS. I've reproduced the situation at itcd2.fogbugz.com (eval. version).

Let's take an edge case. 1 user set up, 2 projects (project 1 and project 2). Each project has one per project milestone. Plus one global milestone.

Two cases assigned to one user. A 100 hour case in project 1, per project milestone with priority 2. And a 1 hour case in project 2, per project milestone with priority 5. It seems reasonable in that case, that EBS should tell that project 2 milestone ship date should come after project 1. But EBS tells us the opposite, ignoring the priorities.

But here is the magic: if i change per project milestone of 100 hour task to a global milestone, EBS starts to produce correct results.

Even more, now if i change the 100 hour task priority to 7 (telling it should be done AFTER 1 hour task) the EBS behaviour does not change.

It seems like when calculating case order EBS always sorts by milestones (even when they don't have any dependencies / startdates / enddates assuming they are all of same priority) and only after milestones goes priority sort (like "order by milestone, priority"). And as side effect of such ordering global milestones work always preceding per project milestones.

I guess there is a need for "milestone priority" editable column? Or smth like that?

Answer 1

Your conclusion is correct. EBS orders milestones by hard dependencies, then by official expected completion dates, so there is a single, global ordering of milestones. Each user is expected to finish all cases assigned to him within the first milestone, then move on to the next, then the next, unless he has set per-project percent times on his working schedule.

Ordering the milestones using the priorities of the cases they contain would be a tricky problem, and it would be difficult to say what would be the correct behavior. If a milestone has 1 priority 1 case and 100 priority 7 cases, is it higher or lower priority than a milestone with 5 priority 2 cases?

If we go further, and say that each person should do all of their cases in order of priority, THEN in order of milestone, then we have to assume that the users are grouping all of their high-priority bugs in the nearest milestones, or FogBugz will attempt to parallelize work on all existing milestones, and putting a single low-priority case into an early milestone will make it finish at some time far in the future.

We're looking for better ways to model EBS for teams that are working on many projects in parallel, so any customer perspective you can give us as to how these problems could be solved would be appreciated.

Answer 2

I've dug this up even more by conducting more tests and reading more docs / blogs.

It seems, it's not a bug, but a "feature". Priorities does not affect developer multitasking between projects / milestones at all (althrough, global milestones remain uncertain, i've started a new question for that.

Developer multitasking of EBS assumes that all people divide their work between projects in a hard manner. By default - evently. So, to be clear, if a team member has 50 / 50 time allocation between two projects there is no way to tell EBS that a 100 hour task with priority 1 should be done by that person BEFORE 1 hour task with priority 7 in other project.

I'm not sure if realised behaviour is a correct use case at all (i don't believe in hard percent time allocations) but the use case when project / milestone multitasking is driven by global priority is 100% correct. It's actually a SCRUM way of project multitasking (at least, that's what our SCRUM trainer told us :).

Am i right with my conclusions? Can someone confirm?

And if i am, is their a hope for some kind of switch / checkbox / otherway of telling the EBS that it should respect priorities in the first place (i guess, right after hard milestone dependencies)?

Answer 3

I disagree with ordering by priority.

My issue with ordering by priority is that it's very common to have low priority tasks associated with a release. We mark these as "fix if time, meaning that they shouldn't hold a release.

It's also common to have a developer working on more than one project, and each project might have a number of high priority cases. If we use milestones to group release tasks, than an ordering only by priority could hold up that release's milestone completion date. This doesn't help those of us who are trying to plan multiple projects at once.