Maintenance?

We're often asked how XP deals with maintenance. In a way, XP is maintenance all the time. We start with a bit of code to do a bit of functionality and maintain it forever.

In our XP projects, we've seen far fewer defects than in more traditionally managed projects. Many XP teams are able to release code that is virtually defect free. That's our goal, but when you encounter bugs, treat them the same as new functionality. Create a story for fixing the defect, estimate the cost in your point system, and allow customers to choose whether to fix the defect instead of spending that amount of resources on a new story.

In our experience, customers handle this concept well until you get to a release or the last iteration of a project. As long as a new iteration in which to fix a problem is imminent, it seems okay to put off the fix. However, if you're launching new code to production tomorrow and the customer just found a defect that won't be included until the next release a month from now, or he just changed his mind about how a piece of functionality should work, he can have a hard time dealing with it.

The customer has the last word. If you have a showstopper defect, which would be hard to imagine in an XP project, your release date might have to slip. This is bad, and it's not XP, but if you're adapting XP to fit into a larger environment that includes non-XP groups, it could happen.