Has any one in the community used 'evidence-based scheduling' by Fogcreek's fogbugz to come up with estimates and schedules on your real projects? I understand the basis of this technique (well covered by Joel here http://www.joelonsoftware.com/items/2007/10/26.html) but I am interested in knowing the actual experiences of folks who have used fogbugz on real world projects.


  • I would vote +2 for this question if I could... I am also interested. Commented Dec 9, 2011 at 10:35

1 Answer 1


I didn't use FogBugz although I did adopt the method itself in one team I worked with as I had all the needed data in my task tracking tool.

First, the story

We were splitting our stories, and later features, to so-called development tasks. For each of such tasks we were making estimates in real hours, meaning that we were trying to take into account all the time spent on distracters, context-switching, etc. Then, when a task was finished we were writing down the real time spent on it. Now, whenever we needed to estimate something in detail we could do WBS make our estimates and, basing on historical data, do Monte Carlo analysis (in Excel sheet) and come up with a result.

Second, the issues

I had two problems with such approach. One, to get reasonable results you should keep the same granularity of tasks both when you collect data and when you make estimations. While the former is easy as we did it anyway, splitting few-month-long, multiple-people project into tasks which take 8 hours on average is huge effort. Besides it requires quite an effort to design the whole thing up front.

Another problem is accounting all the time spent on task during later stages, e.g. bug-fixing, to the original task. It is tricky as you think not only about regular tests but also about issues you get from production etc. Eventually, we ended up having another task, one per feature, dedicated purely for testing. Its original estimate was 0 and real time was whatever was spent on unplanned tasks, such as bug-fixing. Theoretically it suited the model, although it wasn't really telling you anything about the quality of someone's estimating skills.

Third, the conclusions

While the method produced pretty good results, whenever I actually used it, it wasn't applicable too often. As we used agile approach to development we didn't want to design in much details up-front, especially that we worked in environment where priorities were changing pretty rapidly.

On the other hand I could get pretty decent coarse-grained estimates using more generic data (read more about the approach). Also I realized that most of the time I didn't need such exact estimates as I could get using Evidence Based Scheduling, thus we mostly abandoned the method.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.