In the realm of agile software development, the efficient handling of bugs is important to ensuring reduction of efforts in most software projects. Rapid identification and resolution of bugs are significant to reduce the effort involved in most software projects and to have a precise overview of the bugs.
Recognizing and fixing bugs quickly is one of the most critical components of successful agile development. With the experience gained through the Digitale Dörfer and Smarte.Land.Regionen projects, we have generated valuable insights and refined strategies for the effective and timely management of bugs. In these large projects, we followed the normal bug handling process: After implementing features, the software was tested and each bug was recorded, prioritized by importance, and moved to the backlog, in every iteration the bugs tasks that are created were selected to be fixed.
However, our backlog was full of many different bugs, and it was a challenge to manage this backlog and select the important bugs to fix. Furthermore, it was a big effort to go through this backlog after a while and check if the bugs still exist or are relevant. In this blog, a method is proposed that is especially suitable for large projects to reduce the effort of managing bugs and to get a clear overview of current and important bugs.
Implementation of Bug-Fix Period
To prevent teams from being overwhelmed with the intricacies of error handling, the introduction of dedicated bug-fix periods depending on the project scope is a strategic way to manage the complexity of bug handling. By introducing these dedicated timeframes, the focus shifts to identifying and quickly fixing bugs. This approach prevents bugs from accumulating over multiple sprints, which are usually forgotten in the backlog, or the number of unresolved bugs from becoming too large. It ensures that teams maintain a clear overview of the important bugs that prevent the project goal from being achieved and facilitates efficient problem-solving.
Conceptually akin to a feature freeze period during release stabilization, where new features are no longer added, and only critical defects can be fixed in a separate release branch. Bug fix periods are typically dedicated to fixing bugs, especially in smaller teams. Less often, these selected team members will implement new features, but the development of new features can still take place in a separate development branch in parallel to a bug fix period. Depending on the scope of the project, the decision on the extent of new feature implementation during the bug fix period depends on the project lifecycle and specific requirements.
In smaller teams, it is desirable to combine one or two developers with the quality assurance (QA) team for this period. This streamlined approach ensures a focused approach and allows team members to actively participate in identifying and fixing bugs. The task of the developers is to fix the bugs found during this time after a decision has been made on the bugs to be fixed. The QA team finds the bugs in this phase and actively communicates them to the developers without creating a large bug backlog. The smaller team size promotes efficient communication and collaboration, which enables faster decision-making.
Depending on the size and type of project, this period can also be adjusted in the form of a product version or a sprint. A bug fixing phase does not exclude normal testing after the implementation of a new function. It is about proving complex or multiple components and their interactions with each other and avoiding unnecessary bugs that do not affect the goal of the software and important functions of the software. This offers the team a clear overview and focus of essential bugs and helps with better planning.
However, various factors should be considered for successful handling:
Period Frequency:
Determine an optimal frequency for the bug fixing period. In larger projects, a structured approach may involve scheduling these sprints in advance and aligning them with the project roadmap. A bug fix period would be particularly useful after implementing complex features or checking the software for interactions with other components that have already been implemented.
Period Duration:
Definition of the duration of bug fix sprints. The time frame can vary depending on the size and complexity of the project but should be optimized for efficient bug fixing without significantly disrupting the regular development flow.
Pre-Release Bug-Fixing Period:
Planning sprints to fix bugs long before the software is released. Although it may seem obvious, sometimes it is decided too late for such a period. This proactive approach ensures that the team fixes open bugs before release and prevents delayed release after critical bugs have been identified, resulting in improved overall software quality.
During Bug-Fix Period:
During the bug-fix sprints, selected developers focus on fixing bugs and use their expertise to solve identified problems immediately. QA team play a central role by actively testing implemented features and ensuring comprehensive quality checks during the bug-fixing process. Fostering collaborative decision-making within the dedicated team helps to quickly address challenges and optimize troubleshooting strategies.
The process of creating the bug backlog and fixing bugs is different here from a normal process of bug handling. The QA specialists first document a list of bugs and discuss them with the developers. Following the decision-making process in the next section of this article, the bugs are ignored, fixed, or added to the backlog for later. The strategic integration of the bug fixing period proves to be crucial in improving the efficiency and effectiveness of bug management and contributes to the overall success of software development projects.
Decision-Making in Bug Resolution
When it comes to handling bugs during a period, things can get a bit confusing. The key question arises: should we address the bug immediately, or is it wiser to postpone the fix? In our projects we tried to test the software after and, of course, there’s the dilemma of whether it’s worth the effort to meticulously track the bug on the task board. Luckily, the solution to this puzzle isn’t as complex as it may seem. A unified decision-making concept can guide the resolution of bugs in agile project management, ensuring a systematic and adaptable strategy. This concept involves considering key factors, such as the criticality of the bug and the expected time to fix, to make informed decisions on when and how to address identified issues. There are two considerations that should be taken into account: Criticality and expected time to fix. Criticality of the bug found in the sprint, which assesses the severity and impact of a bug on the software. In addition, understanding how urgently a bug needs attention, considering both immediate consequences and potential long-term effects. Expected time to fix the bug, which evaluates the complexity and time required for resolving a bug. It helps with planning and prioritizing bug fixes based on the resources and time available.
In our experience, there are typically 2 types of problems that can be found during a sprint, namely not working as designed or not designed as it should work.
1. Not working as designed
This bug category refers to errors that occur during the implementation of requirements or the realization of UX. These are often caused by comparisons of the software between requirements described by tasks or user stories and existing software.
What to do?
For such issues discovered during a bug fix period, we essentially have three strategies:
Fix it Now:
These are bugs that are not difficult to rectify, and their elimination improves the quality of the software. They can be critical, but also normal bugs. These bugs are only fixed in a single task, together with all other „Fix-it-Now“-bugs that are created for the track back, and do not require a separate task.
Implementation: Small documentation and no additional task; address it as part of ongoing work.
Communication: Raise the issue in the daily scrum for team awareness or report it to the corresponding developer.
Keep the team informed during the daily scrum to maintain transparency.
Example: A bug in an e-commerce app that prevents users from completing purchases should be fixed immediately.
But what if the bug is more complex and could potentially impact the team’s progress toward the sprint goal?
Fix it Later:
These bugs are critical or even normal, their elimination is significant for the quality of the application, but which are complex to fix and require further decisions or discussions for their elimination.
Implementation: Create a new backlog item and plan it for future iterations.
Communication: Clearly communicate the observation to the product owner (PO) and the team. Effective communication with the PO is key to making informed decisions.
Example: The team discovers that the push notification system sometime fails to deliver real-time updates.
And then there are those rare instances when a bug seems minor or the impact of not fixing it is negligible.
Ignore It:
These are bugs that can affect the quality of the software, but do not always or rarely occur. They can also be a bug that is too complicated to fix. But in this case, the right decision should be made about their circumstances, these bugs may or may not cause more critical errors in further versions.
Implementation: Do nothing; accept the risk with the understanding that it may resurface.
Communication: Only the conversation about the case with the development team, no specific communication with other team members is needed; assess the bug’s significance. Sometimes, the best course of action is inaction. If the bug is not worth the effort considering its impact, accepting the risk might be the pragmatic choice.
Example: There is an issue with displaying side data on a specific device/specific OS version.
2. Not designed as it should work
These are cases where user experience enhancements, usability improvements, or feature requests can lead to friction between user expectations and developer compliance with predetermined behavior. They are not really a bug per se, but rather a change/feature request, as these requests are not yet defined as part of the software. Nevertheless, some user expectations are natural, and these are indeed a bug. For example, in a modal form in which a user has filled in many fields, the user expects that the window will not be closed immediately if he/she accidentally clicks outside the modal.
But these cases often manifest themselves in bug reports that come from outside the team (customers encountering problems in a production version) or from quality testers within the team who act as champions of customer expectations.
What to do?
Involves the PO/Designer asserting the newly located issue. Regarding the importance of the reported issue, the PO/Designer can decide. This decision encompasses considerations of its impact on the user experience, alignment with strategic objectives and overall priority. In case of important, a change request can be processed.
This shown bug handling strategy provides teams with a clear framework for bug resolution, aligning decisions with project priorities and maintaining flexibility in addressing varying levels of urgency and complexity. The unified decision-making concept is a valuable tool in enhancing the efficiency and adaptability of bug management practices in Agile projects.
What can we learn from this approach moving forward?
A strategic approach to dealing with bugs is very important to the success of agile projects. By implementing bug fix periods and applying decision strategies based on criteria such as urgency and expected resolution time, teams can increase their efficiency and optimize project progress. In this way, we not only test our software qualitatively, but also create a clear overview for the team and focus on important and critical bugs as the normal bugs are already fixed in this period. A well-thought-out bug handling strategy ensures a smooth agile development process and ultimately contributes to the success of the project. These strategies can also be a starting point for further quality measures, e.g. to automate only critical bugs found in this period; this will also reduce the effort for automation, but it still needs further research.
Further Readings
|
|
|
|
|