In traditional project management, bugs are often separated from requirements or even managed in dedicated tools named “bug trackers”. In agile methodologies, if you keep separate backlogs for user stories and bugs, then the Product Owner cannot clearly materialize their vision, developers don’t know what to implement next and stakeholders don’t know what to expect next. For it to be effective, there must be one and only one unambiguously ordered Product Backlog.
For this reason, bugs are managed as stories in iceScrum and receive very little special treatment. If you further think about it, user stories and bugs are actually not so different: both express a desired behavior that the product does not currently offer.
Only two fields differentiate defect stories and user stories:
The Defect story type, which makes clear that the story is a defect to be fixed. A “bug” icon is displayed on the post-it.
The Affected version field, which points to the product version affected by the bug (e.g. a version associated to a previous sprint).
Creating an effective defect story is as simple as filling these fields in combination with regular story fields, e.g. a proper description, attached screenshots to demonstrate the issue and a dependency to the done story that it relates to.