How to Handle Bugs Found Within a Sprint | David Tzemach
Updated: Mar 3, 2022
Almost any Agile development sprint that involves both coding and testing activities increases the overall potential of bugs. These bugs, related to new development, lead to many common questions addressed below.
Should we open bugs found as part of internal development?
This question is mainly focused on bugs found during new feature development, i.e. code that is still not released to a production environment.
These bugs, which are part of ongoing development, are usually fixed within the same sprint to allow the team to meet the Definition of Done.
So, if these bugs are found as part of internal development, is it necessary to waste time on reporting them, or is it more efficient to fix them as soon as they are discovered? The answer to this question depends on many factors (e.g. team capacity, team maturity, etc.) that usually lead to one of the two options:
Not opening bugs – In teams that are very mature in Agile and also in the technical aspects of their product, this is a great chance to save time. For internal bugs, there is a conversation between the team member who found the bug and the programmer that is supposed to fix it.The agreement is that if the programmer can fix the bug immediately and also add a dedicated test to the existing automation there's no need to log the bug in.
Internal bugs should be reported – The main reason for Agile teams to use this approach is the value it adds. Here are just a few examples that demonstrate it:
It allows the team to search for patterns by conducting an RCA to learn how they can improve in future sprints by preventing similar issues from recurring.
It allows the team to know how much of their time is wasted due to the feedback loops that are part of the development lifecycle.
It allows the team to understand the real quality of their code and the effectiveness of their testing process.
Should we always fix bugs within the same sprint as they were found?
Below are some rules for deciding whether to fix bugs in the same sprint in which they are found or not.
The rules assume that each bug that is NOT fixed within the sprint is communicated and approved by the Product Owner.
Bugs that are holding the team back from meeting the acceptance tests of a story - Fix
All bugs with the severity of "Blocker" or "Critical" - Fix
All bugs that counter the story DoD - Fix
Any bug that blocks other stories of the sprint - Fix
Any bug that blocks other teams working on the same project - Fix
A bug that counters the Definition of Ready (DoR) of stories that are targeted to be delivered in the following sprint - Fix
Bugs that do not add risk to the current delivery – Do Not Fix
Bugs with low severity – Do Not Fix
Bugs approved by the customer for handling in future deliveries – Do Not Fix