Evidence Based Scheduling

Developers don't like writing schedules. They're a pain to write and often don't seem realistic. I found a system for writing them called evidence based scheduling. The complete description can be found here but here are the highlights:

1:break things down into small timeframes, no more than 16 hours. Large timeframes like days and weeks leaves what actually needs to be done extremely nebelous. With smaller timeframes you need to find out what's actually coded.

2: track elapsed time. Chart estimated time for tasks vs how long they actually took. This gives a nice velocity metric. Keep this 6 months back.

3: when estimating the time it will take to complete future tasks, run a Monte Carlo simulation assigning random values from the person's velocity history to each task. The estimates and their conversion to calender dates can be automated, and the averaging against the person's velocities will help give a better estimate.

Interesting enough, because of the way the estimates are calculated, interuptions to the coding time don't need to interupt the “clock” with elapsed time. The number of times that velocities where time taken involves one of those interruptions are used is very similar to the chance that those interuptions will happen.

4: manage the projects actively. You can see how cutting lower priority effects ship dates, estimate ship dates for each person, and use these to make changes

The method kind of reminds me of some of the artifacts used in SCRUM and other agile programming methods. I'm guessing something like this would be easy to integrate.