[NDizzle]

Legacy bugs? What the hell are legacy bugs?! What about, you know, normal bugs. Normal, unforeseen problems that happen all the time that you can't account for. Do you just add 25% time to any project to cover for those? I'm not sure how that solves the issue when you have to slice everything up into tiny chunks, where a few chunks could contain all of the unknown unknowns.

It's good to realize the known unknowns, but it's the other kind that will get you.

[couchand]

Legacy bugs are those in the codebase from before the team started working with a test first, no bugs mantra.

As I alluded to there are many approaches to this problem, but one that I like is more or less just what you suggest: set aside some amount of time every sprint to tackle the legacy codebase. The eventual goal is to bring it up to the newly accepted standard which requires tests, but realistically that will take a while. Live bugs provide a sort of direction to help facilitate updating the legacy codebase. Setting aside a set amount of time each sprint makes sure that the issues don't get swept aside.

It's important to get to the point where fixing live bugs isn't impeding the development of new features, but until then it's simply pragmatic to set aside some amount of time to hedge against new issues, while also having the discipline to set one aside if it can wait until the next sprint.

As an aside, some of the best patterns on the subject of dealing with legacy systems can be found in the later chapters of Domain Driven Design by Eric Evans, particularly chapter 14, Maintaining Model Integrity.