tag:blogger.com,1999:blog-3356724893663618112.post4546271220772102277..comments2024-01-29T00:10:36.064-08:00Comments on Agile Booknote: Yet Another Bug Versus Feature PostFederico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-3356724893663618112.post-66560050282575244002009-09-23T16:13:49.442-07:002009-09-23T16:13:49.442-07:00I think the distinction between 'bug' vs &...I think the distinction between 'bug' vs 'feature' is not particularly important during the course of an agile project. Both represent 'undone work', and it is up to the Product Owner to decide the priority for each to be done. Furthermore, in both cases, tests need to be defined to automatically tell us when they are done. <br /><br />I prefer to use the term 'anomaly' when a (potential) bug is first noticed or reported. At that point it is simply a difference in actual versus expected behaviour, but the expectation itself could be wrong. Thus, a reported anomaly or bug is just an opinion, until the PO agrees that the system behaviour needs to change in an explicitly defined (hence testable) way.<br /><br />Usually the arguments over 'bug' vs 'new feature' are caused by team members being measured on unhelpful metrics.Anonymoushttps://www.blogger.com/profile/15662780537562887336noreply@blogger.comtag:blogger.com,1999:blog-3356724893663618112.post-34096244023657425402009-09-21T15:25:25.250-07:002009-09-21T15:25:25.250-07:00By slicing the user story into vertical slices suc...By slicing the user story into vertical slices such that the first slice is a single "happy path" scenario, and each subsequent slice adds more scenarios including handling various errors and unexpected situations, then the discovery and refinement happens during the feedback to slice N and the final definition of slice N+1.<br /><br />Then bugs will only be when the current slice does not actually handle the agreed upon scenario, not when testers or customers discover some situation that was not covered.Unknownhttps://www.blogger.com/profile/13367961688180787236noreply@blogger.comtag:blogger.com,1999:blog-3356724893663618112.post-87164596252209258252009-09-21T08:25:45.884-07:002009-09-21T08:25:45.884-07:00Nice post. I agree with your thoughts "it doe...Nice post. I agree with your thoughts "it doesn't even make sense to make this distinction." and the important is the learning process. However that's not always true for the team members. To them the distinction is sometimes important, emotionally speaking. So a basic agreement on how features vs defects will be categorized and who will take the final decision on it, could be useful for teams which are starting.Emiliohttps://www.blogger.com/profile/11179437028940203445noreply@blogger.comtag:blogger.com,1999:blog-3356724893663618112.post-11895629404484196812009-09-19T15:06:49.573-07:002009-09-19T15:06:49.573-07:00Perhaps could be a good idea, sometimes separate t...Perhaps could be a good idea, sometimes separate the responsibilities for Validation and Verification. While VER is responsible for "verification of the product and intermediate work products against all selected requirements", VAL is responsible for demonstrates that the product, as provided, will fulfill its intended use; whereas, VER addresses whether the work product properly reflects the specified requirements. In other words, VER ensures that “you built it right”; whereas, VAL ensures that “you built the right thing.”<br />Then VAL can decide if the if the bug is a bug or is a feature request. <br />Another aspect to keep in mind is the experience of the team using AGILE. Isn't easy for a Q member, add a new switch to analyze if an issue is a bug or a incomplete feature, the same happens with any team member without an experience in agile.Shrekhttps://www.blogger.com/profile/16181850163639602617noreply@blogger.com