We've been using an Extreme Programming-like system to do the scheduling for my team, but I got sick of juggling file cards around when people slipped or unplanned features popped up. So we're going to bite the bullet and try Joel's system. One thing that bothers me; we've scheduled as much time for bug fixing as for feature completion but somehow I still don't think it's enough, since we do seem to spend most of our time fixing bugs. Since one of the goals of scheduling is to see if we can get all these features implemented in time, does this massive unknown make the effort worthless?

-- Anonymous, May 16, 2001

Answers

How consistent is the amount of unplanned stuff per iteration? If it's fairly constant, you can make plans just fine. ("We can get 7 cards done per iteration, while still taking care of all the usual unplanned stuff.")

Your question makes it sound, though, like the number is fairly erratic - some iterations you spend 80% of your time fixing bugs, some iterations you only spend 20%. In that case, instead of trying to schedule around the inconsistency, can you fix the source of it? What's causing the numbers to be so different?

-- Anonymous, May 22, 2001

I think Adam basically answered the question. Schedules aren't worth too much unless they're based on historical data. Anything else is just a guess.

You need to start tracking your defect rate (using any measurement you want... defects/kloc, defects/user story, whatever) and then base your bug fixing time on your historical average.

Jay

-- Anonymous, July 17, 2001

It sounds to me like you shouldn't spend that much time fixing bugs.

I can think of two reasons why this is happening. The first is, do you systematically test all features of new units BEFORE integrating? I have personally experienced that even ridiculously simple features WILL have bugs, which can be fixed before integration. But you won't find them unless you test. I reckon most programmers would not even consider the initial bugfixing-while-developing to be bugfixing. It's simply part of development, and it usually goes very quickly. Extreme testing has worked great for me.

Another possibility (also supported by the slips you mentioned) is that you didn't plan your stages in enough detail. Knowing up front exactly what needs to be developed helps a lot in creating an architecture to support it. An incomplete architecture often leads to quick fixes, rather than refactoring sessions, and that's where the hard bugs slip in.

-- Anonymous, July 19, 2001