We are often told that iceScrum doesn’t do much to help manage bugs / defects, backed by the evidence that it doesn’t provide a separate bug system with its own workflow and that defects are seldom mentioned in the user interface.

Actually, this doesn’t denote an absence of feature, it is a deliberate feature! Well, software developers have a tendency to dismiss negative user feedback by saying « it’s a feature! » so you may be becoming a bit suspicious here… Don’t worry I understand and I don’t ask you to take my word for that, I will rather try to explain our motivations!

Defects in agile methodologies

First, let’s forget about iceScrum and start with traditional project management because I think that most preconceptions about defect management come from there. Since requirements are intended to be all known in advance, the product specification is written once and for all. Throughout the project, this document is the comprehensive source of truth telling what the product is expected to be. Deviations from these requirements observed in the product clearly don’t belong to the same document, that’s why they are filed into bug trackers.

Fast forward to agile methodologies, where there is no such thing as an exhaustive product specification document. Of course you may have formal specification or documentation (I hope so!), but the vision of what the product should be evolves continuously and, rather than a document, it’s the responsibility of the Product Owner to embody this vision.

The product is what it is and any desired deviation from its current state must be submitted to the backlog where it is discussed, prioritized by the Product Owner and planned accordingly so the team eventually implements it in the product. Whether this deviation is a missing feature, a defect to fix, a useless feature to remove, a performance problem or a software quality issue doesn’t matter, and this fact is a major asset.

If you have separate backlogs, how does the Product Owner materialize their vision, how do developers know what to implement next, and how do users or stakeholder know what to expect in upcoming versions of the product? For the backlog to be effective, it must be unique and ordered.

iceScrum and bug trackers

Now the title of this blog should make sense: we usually don’t recommend using bug trackers as you know them (i.e. separate tools with distinct workflow) to manage defects. However, you may already have a bug tracker you are used to and getting rid of it at once may not be desirable. Back to iceScrum, that’s why our tool provides integrations with bug trackers, making the transition smooth.

The supported bug trackers are Mantis, Bugzilla, Trac, Redmine and Jira. If you too want to sponsor the support of another bug tracker, please contact us.

The integration is straightforward: people fill bugs in your bug tracker, when they are ready they are imported automatically in your iceScrum backlog where they continue their lives. Changes in iceScrum are synced back to the bug tracker. This way, people who report issues are not forced to learn and use iceScrum when you team start using it, but of course in the long run learning about what really happen to their issues would be beneficial! Read more in the bug tracker documentation.

Defect management in iceScrum

As I said, we don’t recommend any unnecessary special treatments for defects, but iceScrum provides actually two simple ones that we think add value:

• « Defect story » type, which makes clear that the story is a defect to be fixed. An bug icon is displayed on the post-it.
• Affected version, where you can point to the product version affected by the bug (a version associated to a sprint beforehand or a new version that iceScrum doesn’t know about yet)

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.

You can also define story templates to pre-fill stories when you create them so you can define your own default task list, e.g. « Reproduce the bug », « Write a unit test », « Solve the bug »…

Finally, agile metrics such as the project Burndown Chart allow to keep track of the evolution of defect rates, which of course you want to keep low. Apart from that, a defect story continues its life in iceScrum just as any user story.