Agile Bug Definition
Agile Bugs: How to handle Bugs in Agile?
Learn how successful Scrum Teams manage the bugs with Agile methodologies to be predictable and deliver customer value with their products.
Waterfall vs. Agile and the bugs?
In the waterfall methodology, we were defining the requirements, developing, and then testing. We could have smaller cycles of the waterfall define -develop — test, but in the end, we can see the full deliverables only during testing. It practice, it doesn’t matter how much effort the team put into the development; there are always bugs that might take an unforeseen amount of energy to fix them. In the waterfall methodology, the bug fixing can be a long term unknown.
The Agile methodologies help us to prevent the bugs by going through the whole development circle of functionality (user story) in a sprint. In that way, whatever we hold in hand at the end of the sprint, is what is the reality. But what makes the difference is that the scrum team holds the responsibility of the entire process, including the testing of the code and the business acceptance(the product owner is part of the scrum team).
If in your team, user stories delivered are tested by someone outside the team or by the Product Owner after the end of the sprint, you most probably do a sprint waterfall (small cycles of waterfall development).
What is a Bug in Agile?
In software, a malfunction of the system, an error, flaw, or a default in the system, that causes an incorrect result. A bug is when the system doesn’t behave as intended.
The bugs identified for missing functionalities I recommend there are new user stories written, not a bug. The bugs should be for faulty behavior.
Agile Bugs classification
We can classify the bugs by the moment when they were identified: in production, in development (user stories in the current sprint).
The bugs reported in production need to have assigned a priority:
- High priority bug — in this category, we consider the bugs that the core functionalities of the product. For example, for a car software product, an issue that doesn’t allow the user to drive its car will be a high priority bug.
- Medium priority bug — there is a workaround available. For example, I am opening a car with the key instead of pressing the open button of the key. Unlocking the vehicle is a core function of the car, but since there is a workaround available, the bug will be a medium priority.
- Low priority bug — the issue is rather cosmetic or comfort, with no critical functionality.
Defining the classification of the bugs helps for the fast sorting of the defects. The product owner can decide quickly which ones get on the teams’ sprint and which bugs to add to the product backlog.
We could have operational teams and product teams. This article concerns the product teams that do both maintenance of the production product but also the new development of the product.
Do we add user stories to the Bugs in Agile?
There are two scenarios: you can either timebox the time spent on bugs or refine them and assign story points. Let’s have a close look at the options:
Scenario 1: Assign the timebox to the bugs. The team assigns a fixed number of hours dedicated to the bugs, takes them one by 1 to treat them from the top priority of the list. In this scenario, the team can handle one bug or five or an unlimited amount of bugs. There is no prediction on how many bugs the team can do and no commitment to the delivery time. But, at the same time, there is no time lost on investigating the bugs.
Scenario 2: Refine the bugs and estimate them in user stories. For clarification, the bugs are the misfunctioning of the product. Functionalities that aren’t present in the product, they must be handle with user stories, not with bugs. The nature of the flaws in software is very uncertain: they can take a few minutes, as they can make an unestimated amount of time. It might take more effort to find the root cause of a bug than actually fixing it. If you want to estimate a bug, you first need to investigate the issue, look into the code, debug, isolate the problem. If the team spends this effort during the refinement processes and the entire team is involved, it might be a waste of team effort.
I recommend the bugs aren’t estimated but sorted using the priority definition, assigned to the team backlog, and then directly fixed. Any time spent on investigating the flaws is a waste, and most of the time cannot be estimated.
Counting bugs in Scrum team velocity
Above we clarified that the team should not assign story points to the flaws because estimating bugs is a waste of team effort.
By default, velocity means progress, new functionalities that are being developed. A bug is repairing the existing functionality that is faulty. Adding story points when fixing bugs leads to inflation. The team takes credit twice for the same work: one time for developing the functionality and one time for fixing its defects or the complete delivery. This behavior leads the team to do not be that carefully and introducing bugs. In scrum, we do not count story points for defects. We work to minimize the effort spent on bugs or to keep it constant.
How do we deal with urgent bugs in Agile?
Every time I start working with a new client, my answer to this question is: define first the priorities (see list above), and I strongly recommend the tribes to fix the urgent bugs.
While this is a temporary solution to stop a fire, it is the worst long term strategy. Must the bugs be minimized? The user story must contain all the effort involved from creation to production. It includes development, peer review, testing, Product Owner acceptance, integration testing, deployment to the right environment. Only when the entire circle is closed, we can know if the functionality meets the business requirements or not. If the full testing is not part of the user story, then we have a fake velocity. We measure the coding, but not if it did the final customer can use it. For the whole Agile methodology to work, testing must be part of the development of the user story and the velocity.
How to minimize the Agile bugs in your product?
- Increase the code quality respecting the industry benchmarks
- Respect the definition of done and try to bring the user story as close to the production candidate as possible
- Try to identify the bugs early with unit testing, peer review, product owner acceptance. The team fixes any bug found in the early stage of the user story development during the sprint.
You might want to read about:
https://ancaonuta.medium.com/how-to-get-started-with-jira-user-stories-3140f08be714
