Comments on: Converting Bugs to User Stories http://blog.looplabel.net/2009/03/27/converting-bugs-to-user-stories/ programming, technology and human behavior Wed, 23 Jun 2010 00:33:30 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Jørgen H. Seland http://blog.looplabel.net/2009/03/27/converting-bugs-to-user-stories/comment-page-1/#comment-214 Jørgen H. Seland Sun, 23 Aug 2009 20:25:12 +0000 http://blog.looplabel.net/?p=876#comment-214 A bug will always be hard to estimate, as you seldom know how deep the problem goes - if you knew, the bug wouldn't have to be reported in the first place. How you phrase the report will not change this. No matter whether SCRUM is employed, it is (to my experience) far better to get bugs into your regular workflow together with the features. Treating a bug as anything other than a small-to-medium-sized missing feature will often lead to misprioritization, as there is a sliding scale between what is a bug and what is a feature. I can also see that converting it to a user story will also highlight the broken use-case, not just the broken part of the program, which is really useful for prioritization and for coming up with a fix that does not break the overall architecture. A bug will always be hard to estimate, as you seldom know how deep the problem goes – if you knew, the bug wouldn’t have to be reported in the first place. How you phrase the report will not change this.

No matter whether SCRUM is employed, it is (to my experience) far better to get bugs into your regular workflow together with the features. Treating a bug as anything other than a small-to-medium-sized missing feature will often lead to misprioritization, as there is a sliding scale between what is a bug and what is a feature.

I can also see that converting it to a user story will also highlight the broken use-case, not just the broken part of the program, which is really useful for prioritization and for coming up with a fix that does not break the overall architecture.

]]>