How to deal with defects once they escaped into the wild is a much discussed topic in the Agile community. Some people like to add them to the product backlog, others prefer to maintain separate bug lists. Most seem to agree that fixing a bug should be scheduled by the Product Owner just like features are.
At first glance that makes a lot of sense. After all, just like a feature, a defect is basically not much more than some missing functionality that might have higher or lower priority and higher or lower costs to implement than some other missing functionality.
There is an important property of defects that make scheduling their fixes a bit more complicated, though: a defect in the software system also denotes a defect in our process - a hole that allowed the defect to slip through. And not fixing that process problem will allow more defects to slip out in the future.
I would think that the team should be held responsible for fixing the process to prevent defect slippage in the future. Of course, to fix that defect, you will need to analyze the software defect enough to know what caused it, so that you can prevent similar problems in the future. And analyzing it to that depth probably means that fixing it is then actually a trivial task.
So, what should you do? I don't have the final answer. I do think that applying "Stop The Line" to software defects might be worth an experiment. What do you think?
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment
Thank you for your comment!