Evidence Based Scheduling

Today I read this interesting article about Evidence Based Scheduling (EBS), a scheduling system based on evidence emerging from historical timesheet data recorded by individual developers. I pretty much agree with Joel but I have two notes:

1. Joel says that if you extimate tasks that take more than 16 hours to complete you're "officially doomed", and that you should break up every task to fit within the limit. As a matter of fact, in iterative development you accept the fact that initial estimates are not really estimates, but "kind and tentative answers" based on the experience of the developers. You can't break up all the tasks at the beginning of a project, and even in the middle of it you normally estimate precisely only for the next iteration or two. So the schedule gradually emerges, but it never goes too far in time. It would be unrealistic, and it would not consider the Uncertainty Principle: "uncertainty is inherent and inevitable in software projects and processes". That's the "bad" news for the management. The good news is that the schedule will be more and more precise, though I never thought of the Monte Carlo method (which I'm going to try in the future). Then, I agree with Joel on designing short tasks, but only in the context of the iteration.
2. Joel says that when you're interrupted you should "keep the clock running" and add the "wasted" time to the original task you were working on. I have been using the Pomodoro Technique for quite a time, which has a quite different approach: basically you have a 25-minute time slot called a pomodoro, which is your unit of measurement. You try to manage and pospone interruptions, but if you have to deal with them at the moment you simply cancel your pomodoro, which means that you don't count it as time spent on your original task. At the end of the day you track the number of pomodoros you have completed, and add them up to your personal record. That can give you an idea of how many ideal engineering hours (IEH, a metric used in the XP method) you can work in a day. That's just another way to keep track of the wasted time: you work 8 hours a day, but you maybe have only 5 of them to spend on your project. That doesn't go against Joel, but simply gives another point of view which leads more or less to the same (good) result.
   

I liked the metaphore of the schedule seen as a box of wood blocks. To manage overscheduling you ideally talk the Product Owner and have him choose which tasks should slip to next iteration, which is another way to say which blocks should go into the next box. To quote Craig Larman, "people remember slipped dates, not slipped features".