Comments on: Defect Debt http://www.vinktank.com/analysis/defect-debt/ Pragmatic software testing & development by Kristan Vingrys Tue, 06 Jan 2009 04:03:25 +0000 http://wordpress.org/?v=2.2 By: admin http://www.vinktank.com/analysis/defect-debt/#comment-77 admin Thu, 01 Nov 2007 10:13:09 +0000 http://www.vinktank.com/analysis/defect-debt/#comment-77 I do not agree that defects should be added to scope, this to me is saying that the mistakes the team makes should be covered by the customer. Defects are by nature not what the customer asked for and therefore the team should not ask the customer to pay for them. By adding them to scope there is the chance that the team will no longer see defects as their problem and instead hide them within the scope of the project. The team needs to take responsibility for the defects and do what they can to reduce the defects they are creating and the impact those defects have on the project. I do not agree that defects should be added to scope, this to me is saying that the mistakes the team makes should be covered by the customer. Defects are by nature not what the customer asked for and therefore the team should not ask the customer to pay for them. By adding them to scope there is the chance that the team will no longer see defects as their problem and instead hide them within the scope of the project. The team needs to take responsibility for the defects and do what they can to reduce the defects they are creating and the impact those defects have on the project.

]]> By: Chris Leishman http://www.vinktank.com/analysis/defect-debt/#comment-76 Chris Leishman Thu, 01 Nov 2007 04:32:30 +0000 http://www.vinktank.com/analysis/defect-debt/#comment-76 I prefer to look at unfixed defects as simply additions to scope. If a defect is not related to work currently 'in progress', then a change to the system needs to be made to correct the defect. This is analogous to a new story (traditional scope) that requires a change to be made to the system to implement it. In both situations, you can estimate and track in the same way, and they both affect the overall amount of work required to deliver a 'completed' project in the same way. This also allows the business to prioritise when a defect gets fixed (if at all), the same way they do with new stories. This is different from technical debt, which is not normally captured as discrete, independent work to be completed. Attempting to recover technical debt is usually considered when implementing any story that affects the area of code where the debt has been incurred. I'd like to experiment on a project by tracking defects-not-related-to-current-stories as 'discovered scope' (whilst clearly flagging that it is scope caused by a defect rather than a new feature). I prefer to look at unfixed defects as simply additions to scope. If a defect is not related to work currently ‘in progress’, then a change to the system needs to be made to correct the defect. This is analogous to a new story (traditional scope) that requires a change to be made to the system to implement it. In both situations, you can estimate and track in the same way, and they both affect the overall amount of work required to deliver a ‘completed’ project in the same way. This also allows the business to prioritise when a defect gets fixed (if at all), the same way they do with new stories.

This is different from technical debt, which is not normally captured as discrete, independent work to be completed. Attempting to recover technical debt is usually considered when implementing any story that affects the area of code where the debt has been incurred.

I’d like to experiment on a project by tracking defects-not-related-to-current-stories as ‘discovered scope’ (whilst clearly flagging that it is scope caused by a defect rather than a new feature).

]]> By: Raj http://www.vinktank.com/analysis/defect-debt/#comment-71 Raj Tue, 30 Oct 2007 08:37:13 +0000 http://www.vinktank.com/analysis/defect-debt/#comment-71 I agree with you Kristen, the defect debt should handle like technical tasks within a team, this gives a clear vision of defects that has been created and how much effort needs to fix them. I agree with you Kristen, the defect debt should handle like technical tasks within a team, this gives a clear vision of defects that has been created and how much effort needs to fix them.

]]> By: Nathan Henkel http://www.vinktank.com/analysis/defect-debt/#comment-69 Nathan Henkel Tue, 30 Oct 2007 01:28:09 +0000 http://www.vinktank.com/analysis/defect-debt/#comment-69 <p>Kristan Vingrys writes about defect debt on his blog</p> Kristan Vingrys writes about defect debt on his blog

]]>