Defect Found in Previous Iteration - Bug or New Work?

Question

A previous answer stated that:

On the other hand, if Feature Bar met the Definition of Done in a previous iteration, but bugs were later found after the feature was declared "done," then while you may choose to log it as a bug in JIRA, from an agile perspective it's really new work for a subsequent iteration.

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.

So... is there an obviously 'correct' approach (as opposed to simply being opinion-based)? And if so, what is the rationale behind it?

Answer 1

Does it matter how you name it? All extra work is new work when you look at it from a grammar point of view.

You found work that first was not expected (or planned) in the form of a defect. I guess your question comes down to 'how to handle defects? in an Agile environment'

I think there is only one 'correct' (very opinionated) way:

1. Always place defects on the TOP of the backlog. Using a zero defect policy as described in this answer.
2. Do not estimate defects on your backlog, unless they are classified features/improvements.
3. If you fix defects (without estimations) your velocity will go down relatively. Because fixing defects costs time, but you do not earn story-points.

Technically this adds extra effort to the story that created this defect. If you use an average velocity overtime, it will also give you an more realistic forecast, as defects do just happen. Even when you think your done.

I would advise against re-opening done work, unless it is such a big mess that it should be just be re-done.

Answer 2

The short answer is, "Yes."

Niels is right that it really is just grammar semantics. No matter how you look at it, it is new work. One thing to remember is that at any time before the feature/product is live, it can be de-prioritized. Perhaps the defect turns out to be a really nasty infrastructure problem that will require months of work. At that point the Product Owner may decide not to put the defect on the backlog and not ship the feature/ product.

So in this I guess I do differ with Niels a little. All defects go into the backlog. The product owner has to make the business decision of if it needs to be fixed. There are a wealth of reasons a feature might be descoped or even a decision to ship with a known defect. Is it good technical practice to ship with a known bug? No. Can there be business reasons? Yes. At the end of the day the Product Owner decides what gets built, the engineers decide how. (Does give a little incentive to build it right in the first place).

With my teams I have found that refining the definition of the new work is helpful. We have Bugs and Defects. Bugs are anything that is found after the sprint ends and before it is live in production. Most of our teams are on monthly cadences with two week sprints so we often find things when everything gets put all together for the releases. Defects are anything found in production, no matter if it is found by an inside person or outside person. Defects are addressed based on whatever the existing support arrangement is, so may be automatically driven up the backlog.

Answer 3

TL;DR

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:

bug
an error in a computer program or system.
synonyms: fault, error, defect, flaw

defect
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.

Answer 4

I can tell you how my project handles this kind of thing, not necessarily what the objective "correct" way is. I do believe that we are a good basis for consideration as a very large project that has thought though many, many issues over the course of several years.

For us, "Definition of done" means "done" from the perspective of the dev team. Each development team agrees cooperatively on a number of items without which they will not consider a story to be "done". This is over and above any acceptance criteria on the story. This definition of "done" can actually be different depending on the team that agreed to it, because it is a product of "self organization". Generally, the project sees a pretty consistent set of things on the "definition of done" list though.

Once the story is "done". It will go through a number of different types of testing. We do "scrum testing" inside the dev team before we "release" the story into the build, and once it is included in the development build, it will have to go through multiple iterations of testing in different environments before it finally reaches production. This means that a team could hand off a story as "done" and have a defect come back related to that story months down the road. It doesn't make sense in this circumstance to not consider it "done" until ALL defects are resolved, especially since functional, customer-facing behavior might depend on external dependencies (like, say, the customer upgrades their standard browser to IE11). Defects are endless, since there are so many externalities that can change the way the product behaves from a tester's viewpoint.

Now, the way we work with our customer, there is a big difference between a defect and an enhancement. That is because a defect = the difference in behavior between the delivered product and the agreed upon scope for that release. If the product is not behaving the way we all agreed that it should up front, that will be a defect and we are on the hook to make sure it is made good. An enhancement is a different story. Often, as UAT (User Acceptance Testing) testers are digging into new functionality, they see ways that this could be improved to make their lives easier and give them a more productive workflow. These suggestions are captured as enhancements. Since enhancements are not part of the formerly agreed upon scope for that release, but they grow organically from the new features, these are treated in a different way for contractual and billing reasons.

So, going back to the OP: the feature bar met the definition of done in a previous iteration, so it is "done." Later, "bugs" were found, so these would either be defects (if the bug interferes with the intended functionality of the feature) or enhancements (if the testers realized that they really didn't want exactly what they asked for once they got it in front of them). If I had to guess, I would say that 90% of the time we are talking about an enhancement here.