How to Manage Bugs in a Distributed Team

Defects or bugs are common in any software development process. In agile, there are numerous ways to trap a bug, such as testing and verification and validation. Testing can consist of unit testing, system testing, regression testing, and smoke testing. Verification and validation involve regularly showcasing working software to teams; the procedures are used primarily to confirm functionality from the customer's perspective.

Bug management in a distributed team

In a distributed team in which Scrum team members are not colocated, bug reporting and management are critical. A distributed team is connected by collaboration tools, which are necessary for bug management. Agile recommends pairing developers and quality analyst(s) to simultaneously develop and test the story. The story is considered complete when it satisfies the acceptance criteria. 

However, in practice there are always bugs that escape the scrutiny of the developer, quality analyst (QA), and even the product owner who accepts the story as complete at the end of the sprint. In such cases, bugs can be discovered in forthcoming sprints.

During a Scrum sprint, when the team is developing certain features and identifies a bug, members often ask the following questions:

• Where do we log the bug? Should we use the same product backlog or create a separate backlog? Or should we avoid logging the bug?
• How do we handle reported bugs? Should we fix the bug as soon as it occurs or determine its level of priority in subsequent sprints?
• What statistics or reports should we publish for bugs?
• How do we reduce the number of future bugs?

In an agile environment, the team structure is one of the primary factors to consider when managing bugs. It's good practice to use a single product backlog for logging epics, stories, or bugs. In JIRA, one can choose the issue type for the bug that is being logged. When the bug is identified, the team logs it in the backlog and links it to its corresponding story. Linking the bug to the story facilitates the identification of the root cause of the problem. This analysis enables the team to improve the code in the upcoming sprints.

There are several ways in which bugs are discovered during the development cycle.

Developer identifies the bug

During unit testing, the developer has identified bugs and may prefer to not log them in the backlog because the development phase is still underway. They can address them while completing development.

Quality analyst identifies the bug

In a Scrum Team, QA prepares the test scenario at the same time the developer is coding. As soon as development is completed and the developer commits the code to the QA environment, QA performs manual or automated testing and communicates to the developer any failed test cases. 

The story is not considered complete and it cannot be marked as resolved until it has a failing test scenario. It's possible that QA failed to predict a test scenario that may surface in a later sprint or may be discovered by the user. In any case, any bug identified during or after the sprint should be logged in the backlog and linked to its respective story.

Best practices

Below are a few best practices for managing bugs when they are identified during or after the sprint.

Bug is identified during the sprint

In this scenario, the QA performed all test cases to satisfy the story's acceptance criteria. Since the team is distributed, the QA must log the bug in the backlog and link it to the corresponding story. The developer or team is expected to fix the bug as soon as it is reported, and the fix should be a part of the current sprint. If multiple bugs are found and cannot be fixed in the current sprint, then some of them should be carried over to the following sprint, and the story cannot be included in computing the sprint velocity.

Bug is identified after the sprint

In this scenario, the team, QA, and the product owner consider the story complete and mark it as resolved. However, the business user or team later detects a bug. Such bugs are classified as "escaped" bugs. Those bugs occur because of unreported technical debt, a misunderstanding about the acceptance criteria, an immature Definition of Done, or a premature elaboration of the story.

In this situation, the bug must be logged in the backlog and prioritized. The team decides when to handle the bug. If the bug is critical and needs immediate attention, then it must be fixed in the running sprint or in a subsequent sprint. The product owner, Scrum Master, and team decide on a case-by-case basis whether to include the bug fix in the current sprint. If the bug does not require immediate attention, it is taken up in the subsequent sprint planning.

Gathering statistics for better insight

Teams can extract insight from bugs by analyzing bug statistics. Teams can produce the following suggested reports to collect statistics:

• Number of bugs resolved during the sprint
• Number of bugs reported in the story
• Number of bugs reported in the epic or theme
• Number of hours logged against the bug, per sprint (the number of hours logged against a particular bug helps to better estimate bug handling)

Understanding the significance of the above statistics will help improve the following areas:

• Story acceptance criteria: Exposes any gaps in the acceptance criteria, which helps with building a more exhaustive set of acceptance criteria for the story in the upcoming sprints
• Definition of Done: Enhances the Definition of Done and provides more clarity
• Process of story elicitation or elaboration
• Technical debt: Avoid any technical debt after gaining a deeper knowledge of bugs through root cause analysis

The team can discuss these statistics during the sprint or retrospective.