Back to blog home

Bugs and defects: why you should treat them differently

How many of you have wondered about the difference in bugs and defects? How many would argue they both are the same? And how do you define if an issue is within or out of the scope of a sprint?

In this blog, I’d like to look at what defines a bug and a defect, why I think they are different, and the benefits for keeping them separate. While differentiating bugs and defects won’t address every issue within a sprint, having clear distinction for these terms definitely helps to keep your team focused on what you have agreed to deliver.

Let’s start by defining these terms. Dan McGrath, a product manager for Google Drive, defined them on a programmers stack exchange site as this:

A bug is the result of a coding error

A defect is a deviation from the requirements

That is: a defect does not necessarily mean there is a bug in the code. It could be a function that was not implemented, but is defined in the requirements of the software.

I would agree to a certain extent with the above definitions. I always think these terms should be considered differently in any system development life cycle; mainly because it gives a clearer understanding of what needs to be addressed in any given sprint. In the following, I’ve broken down the difference between bugs and defects and how these can affect a project team’s workflow:

Bug - Any issue that arises due to a coding error that happened within the sprint should be considered as a bug, and the team working on the current sprint is responsible for fixing this before the sprint ends. The story associated with this code change should not progress through the workflow without the issue being fixed.

The success or failure of the sprint is another debatable topic. The bottom line is that the story against which a bug is logged should not have a ‘Done’ status until its resolved. It’s always recommended for bigger teams to raise bugs as bug subtasks against the story, and include detailed steps so it can be reproduced. For smaller teams this is not always necessary and can be described in comments as the teams will be working quite closely and will likely be more familiar with the issue.

The bottom line is that the story against which a bug is logged should not have a 'done' status until it is resolved


The responsibility for fixing bugs depends on the workflow your team follows. For example, in a project following Kanban structure, it could be picked up by any developer. For teams where individuals are responsible for fixing issues caused by their actions, then the fix would be assigned to the respective developer.

Defects - Issue found by a QA engineer or team member that are in the system, but not related to the current work, are called Defects. These should be raised along with a description of how to reproduce the defect and should be assigned to the backlog and not the active sprint, irrespective of the criticality of the issue.

The issue can be of any kind. It could be a coding error that happened in previous sprint, or a functionality missed at any earlier stage, for example. The Product Owner (PO) should have the ultimate say on how critical the issue is, and how it should be prioritised for a future sprint. If the defect is critical and the PO wants an immediate fix, then this should be estimated and bought into the current sprint only after moving out a user-story that will free up the equivalent, or more, resource capacity of both Developers and QA engineers.

Confusion between issues and who is responsible for fixing them is directly proportional to time wasted


Once created, the defect is not assigned to any developer, but either to the Project Manager or PO. The defects only gets assigned to a developer when it gets picked up in the normal workflow.

In short, I think clear distinctions for these terms can help a team to understand what they actually need to work on. Confusion between such issues, and who is responsible for fixing them, is directly proportional to time wasted - which obviously has an implication on the overall cost of the project. By defining the difference, and understanding who takes responsibility for the fix, team efficiency can be greatly increased.

Related reading