tag:blogger.com,1999:blog-13831777.post739896998790328750..comments2008-06-19T23:24:17.166-04:00Damon Poolehttp://www.blogger.com/profile/16561311551267979837noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-13831777.post-69456887604557590592008-06-19T23:24:00.000-04:002008-06-19T23:24:00.000-04:00Brendan,<BR/><BR/>Thanks for your comments. Good points! You may also like my updated version of this post which is here: <A HREF="http://blog.accurev.com/2008/03/28/adrift-in-a-sea-of-conflicting-priorities-and-assignments-heres-a-life-preserver/" REL="nofollow">"Adrift in a Sea of Conflicting Priorities And Assignments? Here's a Life Preserver."</A>Damon Poolehttp://www.blogger.com/profile/16561311551267979837noreply@blogger.comtag:blogger.com,1999:blog-13831777.post-1129100435639706002008-06-19T20:15:00.000-04:002008-06-19T20:15:00.000-04:00I like the idea of root-cause analysis, especially if agile is meant to be a process whereby process is continually adapted for improvement.<BR/><BR/>Sometimes it's difficult to determine where improvements are best made without some data to analyse. In my opinion gut feeling is good, but it's not always the only solution, especially when you've got to convince others who don't have the same gut feeling.<BR/><BR/>The other great reason to record defects is so that future developers can use the lessons learnt. Even if you do write new test cases, these might not capture all nuances, and as with any job, people come and go. Creating an environment whereby lessons learnt are captured even if in minor detail helps. (I know this is breaks the peeps over docco view, but that's really argueable from a future peeps point of view.)Brendan Walkernoreply@blogger.com