Bugs and defects (however you choose to define them) are always new work from an iterative development perspective. While some may disagree with the term "new," anything that doesn't fit within a single iteration should be (re-)scoped, (re-)planned, and (re-)prioritized in future iterations regardless of the source of the work, and regardless of whether or not these activities were performed in previous iterations. In other words, the work should be treated as new when it comes into scope, even if it's been on the backlog for six months.
Agile practitioners sometimes disagree about how to do these things because of organizational policies and how they've implemented their project-tracking metrics. However, who would want to argue that bugs and defects aren't things that will direct resources away from other things in other iterations, and that they therefore don't represent "work?" That line of reasoning would be pretty hard to defend!
Done Doesn't Mean Perfect
However, while I can see that a feature not working before the feature is considered Done is obviously just evidence that the feature isn't Done yet, I'm having trouble wrapping my head around how something not working after the feature was considered complete being anything other than a defect.
Just because something is "complete" in terms of the Definition of Done doesn't mean something is guaranteed to be free of bugs or defects. It just means a work increment met the defined objectives and quality goals for the iteration!
Bugs vs. Defects
The distinction between bugs and defects is subtle, subjective, and (at least from a pragmatic viewpoint) probably immaterial. Google offers the following definitions:
an error in a computer program or system.
synonyms: fault, error, defect, flaw
a shortcoming, imperfection, or lack.
synonyms: fault, flaw, imperfection, deficiency, weakness, weak spot, inadequacy, shortcoming, limitation, failing
They are largely synonymous, but in my own practice I differentiate between them this way: a bug is an unexepected error, while a defect is a gap between current state and specifications/expectations. For example, consider an imaginary calculator app with the following qualities:
- The app calculates that
2 + 2 = 5. This is a bug, because it is an unexpected error.
- The app ships with basic operations like addition and subtraction, but lacks a power operator. This is a defect, because it doesn't meet the expectations of the target audience of rocket scientists, but is not necessarily a "bug."
However, even though one may draw a distinction between bugs and defects, it is not inherently useful to do so. In either case, bugs or defects represent potential work for the team if and when they come into scope during iteration planning.
Prioritizing Backlog Items
In the case of a defect, the team may simply have not gotten to the implementing story yet, or perhaps no one even thought this feature would be needed so there's no story on the backlog yet that covers this issue. This may not be an omission: agile development is about minimum viable product and emergent design!
In the former case, if there's already a story for it on the backlog, it's up to the Product Owner to prioritize the story in terms of its business value. Maybe there is other work that is more important to deliver first, or perhaps this feature is so critical that the power operator should be delivered before anything else. Only the Product Owner can make the final decision! In either case, since the story hasn't been started yet, it is new work for the team.
In the latter case, logging a defect is only a placeholder for generating a new Product Backlog Item to describe the feature or functionality to be developed. Because this functionality is not currently in the product, developing it is still new work for the team. It is up to the Product Owner to decide when capacity will be directed towards this new work by adjusting the Product Backlog.
Pragmatically, bugs aren't really any different from the defect examples above. Fixing the bugs still consumes team capacity and requires new work effort, and should therefore be tracked. In many agile systems, the measure of team capacity to deliver work is velocity, and therefore treating bugs or defects as non-work skews the metric. In addition, not treating bugs or defects as new work often leads teams into anti-patterns such as:
- Not scoping the work properly during iteration planning.
- Not estimating the level of effort required to complete the work.
- Bypassing the Product Owner or the prioritization process, e.g. by placing bugs/defects at the top of the backlog regardless of business value.
The point here is that work is work, from a team-capacity or iteration-planning standpoint. The difference (if any) will be a matter of organizational policy and prioritization within your chosen project/product management framework.