Extreme Programming Challenge Twenty

We have many products already in the field, most of them in various states of disrepair. Half our work is new development/refactoring, but the other half is bugfixes. Each bugfix is already recorded in a bugtracking database, so writing UserStories that say "see bug 3678" seems a little foolish. Also some bugs are really simple, and take 5 minutes, while others are fiendishly difficult, and take 3 weeks, so they're not really things you can estimate as UserStories. And business doesn't really know which are troubling the most customers, so the priorities on them change from day to day.

Why doesn't business know which bugs are troubling most customers? Is the system broke?

Now over time XP should reduce the numbers and difficulties of bugs to much more manageable levels, but in the meanwhile this is problematic. Right now we're noting bugs to fix as EngineeringTask(s), and alotting a certain number of days per iteration to dealing with them, but plainly this is very uncontrolled. What's a poor XProgrammer to do?

You could have a rotating ProductionSupport? role. Ask for two engineers to just fix defects, categorize new ones, and answer the phones. You would only have to be on production support for 2-3 iterations, then the role would pass on (you'd probably want to have overlap between the tenures). Now everyone else can get on with development, the defects get fixed, and if there is a big stink you'll know about it earlier. At first you might even have to ask for more people to do production support, but as the load drops you can do more new stories.

I should refuse to admit any similarity between this problem and SXPQN6612:

http://groups.google.com/groups?oi=djq&selm=an_563178240

The world is full of code that was not started XP... -- PhlIp

...You do it one test and one refactoring at a time... -- KentBeck

Someone wrote a book recently that says:

I can't quote exactly because for some strange reason my copy is not in my cube.

The tiny bits of that book that cover transitioning projects are so simple because they stand on the rest of the art covered in the first part of the book. And their simplicity belies the number of times their author has done them. They are simple because all these times lead to the same conclusions. (How's that? ;-)

But for this challenge the worst problem is PlanningGame. Someone is not feeding the coders bugs that help them develop. They are getting upgrade directives from one source, and a stream of unprioritized bugs from another. Someone thinks that "PlanningGame" means you pull all the bugs out of the bugbase and write each one on a card, so they elide this step.

How about this: have a standing UserStory called "fix bugs". Put an arbitrary number, say, 2 ideal days on it each iteration. Each iteration, distribute these ideal days according to developer load. Best to have a pair on the bugfix story at a time. Chart how many bugs get fixed per ideal day over time. Now this is going to wobble around a lot, but pretty soon you should have a fair idea of the number of ideal days per bugfix. Extrapolate that to the rest of the buglist and then schedule as per PlanningGame. -- PeterMerel

You seem to advise throttling the bug stream. That leads to the worst kind of user disatisfaction - "I've been asking them to fix that one stupid thing for months!"

I think that while bugs are in the field the bug stream should run full throttle until the only ones left have obvious work-arounds or are really "missing features". But I keep thinking that the PlanningGame lets coders select the bugs in the order they need to do them to benefit the infrastructure. That might require ProgrammerOmniscience?, but I've never had a problem with that before. -- PhlIp

I assumed that you wanted to balance development and defect fixing. Fixed resources applied to bugs (it could be 90% if you had enough defects) are one way to make sure both problems get attention. -- KentBeck

I don't get it. I'm not trying to be a jerk (it comes naturally) but this seems straightforward to me.

Defects impact customer satisfaction. Customer satisfaction impacts revenue. Therefore defects have [negative] business value, and fixes have positive business value. Therefore customer should schedule which bugs need fixing.

As for the difficulty in estimating fixes, (a) I don't believe that most fixes aren't already estimatable, and (b) if you start doing it, you'll get good at it, and (c) if you really can't estimate them, do what you do when you can't estimate a task - spike them. -- RonJeffries

Hmm. Please disregard anything I ever wrote that implies JustaProgrammers get to pull out of the PlanningGame items they know they need to do. They can sort by tech priority the short list they take from the game.

BTW, have we answered this Challenge yet? -- PhlIp

Funny, just saw this Dilbert: Pointy Hair says, "Wally, don't do anything until we get the market research data." Wally thinks, "No longer must I put my hand on the mouse when I hear footsteps. Yes!" A little XP creeping into Dilbert or just a fluke?

We treat bugs and new functionality equally. A story is either a defect or a feature. It forces the customer to make some difficult decisions, but it is no more difficult than prioritizing unrelated features in a large application. The defects do tend to be very small, but in the later increments of the project many of the features are small as well.

Also, we found that grouping several defects into a single story did not work for us because we lost visibility when tracking the stories electronically. We just accept that our story estimates for these types of things will be measured in hours rather than days or weeks. -- TomSparks

See CommitmentToQuality ExtremeProgrammingChallenge

EditText of this page (last edited September 14, 2005) or FindPage with title or text search