How to handle defects in Scrum
Found an issue during a sprint! Put it in the backlog
Sound familiar?
Above is a common response when a bug has been found during the sprint. Following the approach to dump everything in backlog results in an overwhelming backlog that’s difficult to contain.
What is a defect?
According to Wikipedia: “A software bug (or defect) is an error, flaw, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program’s source code or its design, or in frameworks and operating systems used by such programs, and a few are caused by compilers producing incorrect code.”
I am going to discuss few scenarios with regards to bugs found during sprint and how they can be managed.
1. A bug has been found that belongs to a feature/task in progress
Agile is not just about releasing more often, but also with complete and tested features. As mentioned by Lisa Caprin in An Agile Approach to Defect Management
Defects needs to be prioritized over new features
Misbehavior over desired features
If the issue reported belongs to a feature that is currently being worked upon, the priority would be to fix it right away. Fixing broken code always takes precedent overwriting new code.
- Some bugs could be fixed with changes in a few lines of code, in less time. They must be fixed right away.
- The other category belongs to high priority , time-consuming bugs. To tackle them you create a task and if the investigation is needed, a spike. Estimate it and start working on it.
- If these bugs found don't have enough user impact but require considerate time to be resolved, put them at the top of the backlog.
If the bug is not important enough to be picked up in the next sprint or two, we should just cancel it. If we’re not going to fix it as soon as possible, most probably it will stay there for ages.
The time team needs to fix a defect in the future will conflict with the time required for new feature development.
2. A bug has been found, which is a task
If the reported issue is
* Intended behavior but missed in the design document
* A behavior that was added after the sprint started
* A nice to have feature but not necessary for the release
In these scenarios, the reported defect should be converted into a task or a feature depending upon its size to implement it.
If the features need to be implemented, the Product Owner will prioritize it. According to which this task might be
1. Added in the current Sprint (If it’s easy to implement without affecting the current sprint’s committed goals or features, fix it! else sprint backlog will be re-prioritized)
2. Prioritize at the top of the backlog to be picked up in the next sprint
3. Planned as separate projects as a Phase 2 depending upon nature
Remember if it is not significant enough, cancel it or defer it.
3. A bug has been found in the Production
Usually, a bug is found in the production environment during regression or scheduled end to end testing. Since lots of users are using the LIVE environment, one cannot deliberately allow them to use a buggy application. If it’s a blocker fix it right away.
For other bugs before prioritizing you must ask yourself the following questions:
- How much user impact it has?
- What business impact it has?
- How much technical impact it has? Meaning is it wise to write a new code at the top of it?
- If we do the hotfix, how much regression it is likely to cause. e.g a new campaign might be scheduled to go LIVE or a client demo is in progress
- If the fix is time-consuming but must be resolved due to its priority, what are the tradeoffs of the planned features we are ready to make?
Conclusion:
If the number of bugs keep increasing and its not manageable in a certain time frame, it's a sign that either we need to
* Do thorough requirement gathering
* Rethink how we do our refinements or planning sessions
* Spent more time in analyzing the acceptance criteria
* Revise Definition of done
* Needs to revisit our engineering practices
Quoting the agile manifesto:
“Responding to change over following a plan.”
The escaped defects should be prioritized in the next sprint or as soon as possible. The team not only needs to resolve the issues but invest time to perform the root cause analysis which will help them in highlighting the improvement areas and take further steps to fix them.
It will become more expensive to resolve the problem later on. With time the team loses context and fixing the bug later will take more time to get resolved.
For any kind of suggestions, feedback or queries, please feel free to comment here or contact me on my email address nidasaleem333@gmail.com
