Do you have bugs on the product backlog?

Mary Poppendieck says that if you're tracking bugs, you've got a faulty process which enables errors. Well, that might be true. As well as it's true that you should be consistent in bringing up your kids or you shouldn't tell lies. For myself, I hate the word bug, as I've written in an earlier post. It brings out the most evil in people. And that is blame. Well, someone made an error, so let's all find him, humiliate him and make him clean up his mess. And that him can be the uncertain requirement's guy who wouldn't give a straight answer, or the stupid developer guy who should have known better, or the idiotic user who doesn't use the program as he's supposed to.

So, let's just leave it there and say there are stuff in the system which we've already built and we're not quite satisfied with how it turned out. The changes are hard to describe in the form of a story, som we just state which part of the system we want to change and how the problem looks. For example:

• When viewing the total sum on a billing detail, the currency is missing
• When printing a billing detail, the address is not included

If it's not obvious you can also add why this poses a problem: this makes it easier for the product owner to set a business value and a priority.

So, the answer to my question if I believe bugs should be on the product backlog is YES! If you don't include them on the list, how can you possibly give them a priority? And should users track two systems? If you're into lean and believe bugs should be fixed first, well then you only give them the highest priority and then you can still give some information to your stakeholders.