Question

I'm trying to get an understanding of how the EBS works for a project with a longer time frame, say roughly a year or more.

In this question, and elsewhere, it is stated that developers should estimate their own time, and that tasks should be broken down to the level of "write this function", estimated in hours, not days. This makes sense when you're about to start working those tasks immediately.

However, say you have several large features you want to get done over the course of your year. Nobody uses the waterfall model of development; your developers are not going to break down an entire year's worth of work into which individual functions to write before getting started on any work. So what is the best-practice for entering and maintaining your schedule in FogBugz when you don't (yet) have that level of granularity? I'd like to get a feel for the process of planning and revising that you would use as the project first starts and as it progresses.

Answer 1

Great question!

I have been put into situations where I have had to do this, and I never feel good about it.

I think that the best situation is to go out and find out what are the "synchronisation points" between your development, and whoever your immediate customers are... whether that be business people, systems engineers or whatever. These are your milestones. (Typically many more than just the "shipping points".) The next thing to do is to make sure that you are continually abreast of all the changes going on outside of your part of the project, so that you can update the "official dates" on those milestones.

The next thing to do is to create cases as you see them appearing, and try to be honest about priority and which milestones to put them in. A true indication of priority is the ideal state to be in though. (In my opinion, never achievable to a perfect state. BTW, "priority" is defined as "relative claim on scarce resources", so it's not an absolute thing, it is relative to all the other things in the pile of future work. It's always changing, too.)

Now it is up to you to keep track of all the "synchronisation points", and all the requests for features. FogBugz can help here.

It is up to your developers to do their decomposition and estimation for the first synchronisation point (milestone). If there is a problem, on the first milestone, you have to do two things: negotiate scope like a mad-man, and consider whether you need more/other resources.

Once your first milestone is passed (whether you had to reduce scope or not), people will feel a lot more confident, and you can start to consider the plausibility of the long-term schedule. It might become clear that the project cannot succeed without some major changes, but better to find out now, and elevate the issues to the project's sponsor. Maybe you will get the extra resources, maybe they will get another project manager.

Then iterate as you go to each successive milestone. The slider in the EBS chart for priority is a good tool, because it helps you to see how eliminating lower priority cases advances your likelihood of making the "official date". The whole thing is one long, on-going negotiation (at least for you.) More scope later, less scope earlier, more resources, different resources, etc etc. Make sure you have your personal stress-management techniques squared away.