Thursday, November 6, 2008

Too Big to Be a Bug

In the vast desert of "it should work this way but it currently doesn't", you have bugs and you have future features. There are a lot of different ways to distinguish between a bug and a feature, including by whether the user would expect it to work or see it as new, or by whether implementation has been attempted. One of them, though, is a bit unusual to me...

It's not unheard of for a developer to put this statement in a bug:

"Bug XXX is too big to be a bug. Please write a story for it."

Wait, what?

This is just yet another way to distinguish between a bug and a feature. What that statement really means is:

"The amount of work required to achieve the desired behavior is large enough that I would like to get credit for it and have it tracked. So please put it in the story process."

You see, like many XP shops, for our development group time spent working on stories is fairly closely tracked. It's part of velocity calculations, it's easily visible to our customers, and it's discussed explicitly quite often. Bugs aren't. They're the "extra" work that's done in the background. Basically, bugs are second class citizens.

Now, bugs found in the initial implementation of a feature are one thing; they're noticed because they prevent story acceptance and therefore get discussed. It's regressions introduced by refactoring, or bugs that are missed in initial testing, or bugs in legacy code (that predates the story process), or bugs that fall sort of between stories (and are found in more general testing) that get treated as "extras."

Bug fixes are as valuable as stories, and should be tracked as closely as stories.

The developer who wants the bug turned into a story instinctively understands this. He's asking for credit for the work he's going to do on the bug. I think he's perfectly right, as well. Fixing bugs is development work and as such should count.

Now, the reality is that I don't particularly like turning bugs into stories. After all, how long something takes is orthogonal to what it actually is (bug or feature, for example). So instead I propose that we start putting bugs in the story queue. That's right. If a bug matters, then put it in the backlog. It's more important than some features, less important than others, and it's development work that needs to be done. Sounds like the definition of a backlog item (to borrow a SCRUM term) to me.

How do ya'll handle bugs in a process that rewards development work but doesn't always surface the time spent fixing problems?

No comments:

Post a Comment