Question

I appreciate that you have a statistical method for scheduling my software release, but my devs are already overtaxed. Asking them to estimate all this stuff is just going to push them over the edge!

Answer 1

In short: NO!

Task not estimated = task not thought of (or requirements aren't read).

It's the same idea as in TDD (think before you start cranking code) but much easer to implement and do.

Every task (even non developer tasks) should be estimated before work started.

Answer 2

The intent of putting in estimates is not to squeeze the most out of developer time, but to measure those estimates against actual performance and use that information to probabilistically estimate when you will finish the work you've put in front of you. The decisions you make with that data will actually reduce stress on your dev team by reducing the unrealistic expectations that seem to go hand-in-hand with software development.

If the developers consistently underestimate the amount of time things will take, and your schedule doesn't take that into account, you're going to be rushed at some point, unless you cut features. EBS allows you to make those determinations earlier, when things are less stressful and deadlines aren't bearing down on you.

When I was a coder years ago, I consistently (verbally) underestimated the amount of time my projects would take, and I was never able to break that habit of hubris. EBS would've accounted for that and made sure that I had the right amount of work to get the release out on time and without stress. And my coworkers wouldn't have had to take on my work (with sighs and tsks) at the last minute when they themselves were overloaded. I was a decent coder and a terrible estimator. (I'm an optimist.) If my company had used EBS (if it'd existed), they would've gotten more out of the team.

We used EBS to release FogBugz 7, and let me tell you, it was nearly a stress-free experience. Things were so calm around the office that anyone walking the halls would not have been able to tell release day from any other day.

Answer 3

In my experience estimating is a time consuming task.

But since we started using Fogbugz it never has been. Why?

This is because of a slightly different perspective.

Before FogBugz, I used all sorts of Excel sheets and documents for keeping track of the tasks. When estimates were to be written down they had to be maintained in different locations.

Using Fogbugz I enter the estimate in one place. This takes 30 secods for each estimated task.

If you are referring to the process of coming up with an estimate this process is also simplified because of the EBS. Before this we had several schemes of doing estimation work such as calculating a mean, and different certainty. Now we use EBS instead.

In short: Estimation in Fogbugz is time saving compared to other methods. At least in our case.