Bugs Are Just Stories

So are Stories bugs? Surely both stories and bugs are subtypes of a single supertype. They both require a Developer to take some kind of action upon the code, require some kind of testing by QA and have some kind of effect on the customer's experience with the product.

Yes. I've decided that, from a user's perspective, any time the system does not meet their expectations, it's a bug. Users' expectations drive all feature requests and all bug reports. Why treat them separately?

And if the user comes to expect poor quality? Many developers have expert knowledge of how the technology can be used to make systems more stable, faster and more user friendly. In any case there seems to be a class of problems that the customer will notice and write up as a UserStory and another where the customer may not even recognize the potential for improvement. -- Kirk Trownson

There's nothing that says programmers can't suggest user stories. But, ultimately, it's the user's system. Whatever the programmers think is best, they're not building it for themselves, they're building it for the users. Let them drive. -- MarkAddleman

You just need a DeveloperStory.

In the beginning there was only one story. Then a programmer came and then there were bugs. Bugs are not stories. Bugs are annoying, that is the reason they are called bugs in the first place. Calling bugs stories is the same as calling a bug a cat. You can do so but the cockroach does not change in a loveable pet. [JimCaprioli]

But he's not suggesting calling bugs cats. He's saying that bugs and cats are animals, and we end up dealing with them the same way, so why don't we just call them animals.

Because at one level they are the same and at another level they are different. When you care about animal stuff you can refer to the animal interface. When you refer to cat stuff you can use the cat interface. A bug is different from a story in that had a particular tester and test configuration that produced the bug. For a fix you will need to make sure you test the configuration that caused the bug. This could range from no big deal to requiring a week setup and several million dollars of equipment to reproduce. You may need to talk to the tester to get more information than is in the test report because it's the tiny details that often matter. So they are different enough to have a separate type and that different is critical.

I don't find that different from a story

[Another way to look at the difference: Bugs are errors in stories that the developer claims have already been implemented. If a story is implemented incompletely or incorrectly, that's a bug. If the story specifies certain behavior, but under some allowable condition the design does not comply, there's a bug. Bugs are often discovered by acceptance testing. However, they can also be discovered during refactoring or code review. Either a bug or a feature can be addressed via a user story. Still, keeping track of bugs separately from features provides useful metrics.]

I'll buy that. Especially if keeping track of the bugs separately helps you track down root causes and types of bugs.

(Urban legend?) I've been told that the state government of Florida has declared that there are no cockroaches in the state of Florida. They simply re-named the creatures "Palmetto bugs". Doesn't "Palmetto bug" sound ever so much nicer and prettier than "cockroach"?

Stories represent substantial work that must be jointly understood by both the developer and customer. Not all bugs are this big. But for those that are, the story mechanism is a good means for scheduling the effort required of them.

Someone answered much better than I while I wrote the below.

Hrm. The software I work on has a number of users who do different things with it. When a particular user wants an enhancement, I create a story card. The card is pretty standard in that it is minimal and really serves as a promise to have a conversation. From my point of view talking to a particular user about a particular use scenario is not different from talking to a particular tester about a certain bug. Both features and bugs can range pretty far in time and money, and both require more talking to get at the tiny details. I can see, however, that in a different project, users requesting feature may be different from testers reporting a bug.

CategoryStories