Why do you love the way you track bugs?
As the titles suggests, I'd like to hear from those in the community that have found a way to track bugs (either in the Sprint, outside the Sprint, both) that they really like. Why do you and/or other members of the Scrum team like it?
I'd like to hear from those in the community that have found a way to track bugs (either in the Sprint, outside the Sprint, both) that they really like.
In the Sprint, add remedial work to the Sprint Backlog. Outside the Sprint, add it to the Product Backlog. Inspect and adapt as soon as possible, such as by improving the Definition of Done.
Why do you and/or other members of the Scrum team like it?
It helps to improve transparency and reduces technical debt.
perfect answer above ;)
Inside the Sprint it isn't tracked, it is fixed. There is no benefit to tracking something that doesn't exist when you declare your increment done.
Outside the Sprint, they go into the Product Backlog and are treated just like a feature request. We use Jira and all bugs are entered as User Stories so that we aren't tempted to treat them differently. The opening sentence of the Scrum Guide section that defines the Product Backlog states
The Product Backlog is an ordered list of everything that is known to be needed in the product.
Notice the word "everything"? Bugs are included in that. Why do we use User Stories for them? Well a User Story has 2 values. Negative as long as it is not done and positive once it is done. Bugs have negative value as long as they exist and positive value when they are corrected. So treat everything the same in everyway.
Thanks everyone for the replies so far!
@Daniel Wilhite
There is no benefit to tracking something that doesn't exist when you declare your increment done.
That resonates with me as a concept, but could we not say there is potential benefit in tracking bugs as a means of documentation to A.) recognize trends related to where they come from so we might find the root cause and/or B.) have symptoms and solutions available for future reference?
could we not say there is potential benefit in tracking bugs as a means of documentation to A.) recognize trends related to where they come from so we might find the root cause and/or B.) have symptoms and solutions available for future reference?
If a team hasn't collaborated to create a Done and defect-free increment by the end of each Sprint, technical debt will be incurred. This has a tendency to compound geometrically until the appropriate remedial work is carried out.
In this unfortunate situation, a team may have little choice other than to resort to a bug tracking system along the lines you indicate. The defective work would be too complex for team members to act on swiftly or to keep track of in their heads.