I teach project management and estimation workshops. Every time I teach estimation, someone asks, "How can we get the perfect estimate?"
You can't. Estimates are guesses. And, if you are multitasking, every estimate you have is wrong. Guaranteed.
But you still need to figure out when things will be done. Instead of estimating how long a task will take, I prefer to estimate how many small things I can complete in a week. And, I make sure I get to done on each task before I take on another task.
One of the problems of estimating large tasks is that we tend to estimate in units that are too large. If you estimate in weeks, you'll be off by weeks. In days, you'll be off by days. In hours, you'll be off by hours. Over the course of a project, even estimating in hours can obscure the actual duration remaining for the project.
Instead of using scope as the base, I use a timebox. Instead of asking, "How long will this take?" I ask, "What are all the small tasks required to complete this piece of scope?" Then I see how many of those will fit into a week.
If you're working with other people, and are using a Delphi method for estimation, you'll discuss your estimate. You'll hear things like "If Danny does it, it's only a 3. If I do it,
it's a 5." I always take the upper estimate. Why? Because if Danny is so good, he's not going to be available. He'll have questions to answer or some other task that's a higher priority. I'll do it anyway. And, if I practice doing these tasks I'm not so good at now, I'll get better pretty quickly.
Think hard about whether you want a good estimate or if you want the work done. Estimating at the beginning of the project is often a waste of time. The more work you get done, the better your remaining estimate will be.
I really like your point about Danny's time being scarce. If Danny is an expert, his availability is going to be scarce. I've observed that over and over again in the work world (from both sides), but I never explicitly thought of it in the context of estimating.
Your observation about Danny is also the reason I like pair programming. Because Danny is going to be fielding lots of questions anyway, it is kind of folly to pretend that he is going to be 100% productive if he is in the office. Better to have him sit with somebody else and make the other person more productive, both in terms of completing the current task and future ones.
Maybe there are times when you really do need Danny-like velocity, and that's when you need to set up an environment where Danny's productivity trumps everybody else's. It involves a ton of tradeoffs, unfortunately, and it is almost always short sighted. And you definitely do not want to build it into your estimate, since it is so risky.
Gold! Pure gold! I cannot understand why people just don't believe this to be the case, but I see it happen time and time again.
Dave Rooney
The Agile Consortium
I agree with your opinion. It is a tough work to find an adequate answer if the customer is asking you when this or that task is finished. Especially when you make changes in the backend for some weeks and the customer could not see any visible results.
One of the best solutions for this problem i found, is to show the customer a mockup (if possible), so he can report his stakeholders that the project is on the right course.
I agree with Siegfried, it's very common to find yourself in a situation where you find it difficult to give an 'accurate-enough' answer on when a project will be completed, especially when you have third parties involved. I remember how hard it was for our team to estimate a web project when we didnt have proper control on the cutomer's CMS system. Estimation was very hard... however a mock-up helped a little bit..