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:
How to deal with Change of Requirements or Scope Creep in Agile?
Here are the questions I ask before accepting a change request? Does it serve the Sprint Goal? What is the business…
Get your Bloody User Story done
Now, a decade later, I know Agile works, if done the right way. Getting the user stories done is the foundation of the…
How to Write User Stories that Deliver Value to the Customer
Before we discuss user stories, let’s clarify what user stories are?
How to define Features in Agile Methodology?
In Agile methodologies, the features represent a chunk of functionality that delivers considerable business value.
Why Velocity Works Better than Man Days Effort Estimation?
What is the velocity metric?
Nine user story metrics I care about while coaching Scrum teams
Goal: put in numbers the team performance. Numbers talk to everyone. When we see 98% performance there is no…
Hamburger Method to Split User Stories from Dev team perspective
The main reason why I use the Hamburger Method to split user stories is to coach the teams to transit from the…
How to Split User Stories
When it comes to defining user stories, I always give the cake examples to the teams I work it.
How and why the personas must be the starting point of our user stories to build better products
This week I started a new project — CooLab. We need to create an application which helps cooks to reach more people…
User Story Definition Of Done (DOD) in Agile Software Development and the Technical Debt
In Agile Software Development, we use the Definition Of Done for User Stories to ensure the quality of work and to…
How to Migrate a Jira Project from a Jira instance to another one
Unfortunately, as of today, Nov 2020, Atlassian Jira doesn’t offer a fully working project export/import, including…