If you’re working in the Agile world, you know there are two words guaranteed to ignite a fiery debate, a spirited disagreement, or at least a confused sigh in any team meeting: bugs and spikes.
These aren’t just ticket types in a tracking tool; they represent philosophical decisions about how we manage our time, measure our success, and allocate our most precious resource – developer effort. Are they necessary evil? Are they a hidden opportunity? Are we sizing them correctly? (Or at all?)
Part I: The Clarity Conundrum—Bug, Defect, or Debt?
The first and most critical step in conquering quality issues is to stop calling everything a “bug.” When we throw every problem into one bucket, we lose the ability to triage, prioritize, and allocate resources effectively. We need to be surgical with our definitions.
1. The True Bug: The Classic Definition
Let’s start with the classic, non-negotiable definition. A Bug is something that used to work, but now no longer does.
This is a regression. This is the application failing to perform a function it was designed and previously verified to do.
- Example: You hit “Submit” on a customer registration page that was functional last week, and now the web page explodes with an error message. It regressed!
- Context: Bugs are typically found in production or immediately after a stable release.
The moment a true bug is discovered, the primary goal shifts from “adding new value” to “restoring expected value.”
2. The Internal Defect: Quality in Motion
When teams are developing new features, QA will inevitably find issues. These are not bugs! A bug is a failure of something completed and released. These are simply issues with work currently in progress, often referred to as a Defect.
What is a Defect? A Defect is a specific type of subtask that lives under the user story currently being worked on in the Sprint. Any issue QA finds with a feature that hasn’t left the Sprint yet is logged as a Defect.
The Power of the Defect:
- Stops the Loop: It short-circuits that common development/QA loop where QA just sends the story back with a vague “doesn’t work, fix it.” A Defect is a clear, trackable item.
- Transparency: It prevents work from happening in the dark. The Scrum Master, Product Owner, and the rest of the team can see exactly what issues are being found during development and why that story might be taking longer than expected.
- Drives Quality: This process encourages the developer to own the fix immediately, as it’s part of the original story’s scope.
3. Technical Debt: The Inherited Mess
Technical Debt is often conflated with bugs, but it’s fundamentally different. Technical Debt refers to non-functional work that needs to be done to maintain the health and stability of the system. It’s the “steaming pile of mess” or the shortcuts we, or previous teams, took that now make future feature development slower, riskier, or more difficult.
- Example: Code that is overly complex and fragile, a server stack running on an outdated, unsupported OS, or a lack of automated testing coverage.
How to Handle Debt: Don’t put huge debt items in the Bug Backlog! The best approach is to fold it into ongoing work. If a developer is already working in a fragile area of the code, allocate extra capacity (and thus, extra story points) to refactor that section as they are building the new feature. That 3-point story is now a 5-point story because we’re paying down debt as we go.
Part II: The Sizing Struggle—Protecting Velocity
The next major debate is perhaps the most divisive: Do we size our bugs?
My initial gut reaction is always no, we don’t size bugs, because they carry enormous uncertainty. A bug is an unknown – it could be a 5-minute config fix, or it could be a complete architectural nightmare taking days. Arbitrarily assigning a size (e.g., “Every bug is a 5”) simply distorts your velocity.
However, theory clashes with reality.
If your team has always sized bugs, keep going! Stopping now will make your velocity tank. If your team has never sized bugs, don’t start! Starting now will artificially inflate your velocity.
The larger issue beneath the sizing debate is the fear that velocity is being used as an external performance metric for individuals. Velocity is an internal team forecasting tool, and when bugs start affecting it, teams may game the system to look better – whether that means undersizing a hard bug or simply leaving it off the board. We must protect the team’s psychological safety and ensure bugs do not mean blame.
Strategies for Handling Quality Work
Since quality work must be done, here are better, more structured ways to handle it than just stuffing bugs into Sprints:
1. The Bug Hunt Sprint
I love this approach. Instead of trying to sneak bugs in alongside new features, dedicate an entire Sprint or a clear portion of time to attacking the quality backlog.
- Goal: The goal is explicitly not to add new customer value, but to improve the system’s health.
- Method: Clear out the Bug Backlog. Triage every bug critically: Is it still relevant? Is it a data issue, or a code issue? Can we live with it? You can even gamify it: offer a small prize to the developer who closes the most bugs (validly!) in that cycle.
2. The Emergent Work Swimlane
Teams often face small, ad-hoc issues that simply must be dealt with immediately. Instead of jamming these unsized items into the Sprint backlog, carve out capacity.
- Plan for Reality: If you know your team only gets 6 working hours a day, plan for only 4 hours of feature work, leaving 2 hours a day (the “buffer”) for Emergent Work.
- Visibility: Create a dedicated swimlane on your board for these items (bugs, small defects, urgent fixes). The work is tracked, the time is allocated, and the planned feature work is protected. This is how we combine the best of Scrum and Kanban.
Part III: Conquering Uncertainty with Spikes
If bugs are about fixing the past, spikes are about preparing for the future.
A spike is a timebox put aside to eliminate technical or business risk associated with a large, ambiguous future feature.
Spikes: Not a Waste of Time
They are an investment in confidence. They reduce the risk and uncertainty of a future project so the team can later provide an accurate estimate (size) and commit to the work.
- Example Use Cases:
- Technical: Researching three potential third-party libraries for payment processing to see which integrates best with the existing architecture.
- Business: Creating a quick prototype to validate a core user flow with stakeholders before building the full feature.
The output of a successful spike should never be working code for the final product; it should be a user story, documentation, or a clear decision that allows the team to size the real work.
The Best Way to Size a Spike
Some teams estimate hours for research (“This is a 6-hour spike”).
Others simply make every spike a fixed size: a 3-point story.
Why a fixed 3-point size?
- Efficiency: It bypasses the time-wasting debate over whether the research will take 4 or 6 hours.
- Consistency: It’s an estimation of effort, not duration. Three points is big enough to show a meaningful investment but not so large that it paralyzes the Sprint.
- Clarity: When the Product Owner asks for two spikes, the team can immediately say, “That’s 6 points of research, so we’ll adjust the capacity for feature work.”
The goal is to stop spiking every user story. If a developer needs 2 hours to investigate how to implement a feature, that time should be baked into the size of the story itself (e.g., making it a 5 instead of a 3) and executed as a subtask – not a separate spike.
The Ultimate Agile Principle: Transparency
If there is one key principle that unifies the management of bugs, defects, debt, and spikes, it is transparency.
Every ounce of effort spent by a developer, QA, or architect is valuable. We cannot allow shadow work.
- If your architect is spending time researching new deployment tools, that work must be tracked on the board as a spike.
- If your developer is spending an hour fixing a small issue found by QA, that should be tracked as a defect.
- If the team has to take on a major code overhaul to prevent a failure, that is a technical debt item that must be prioritized by the Product Owner.
Transparency ensures that the Product Owner knows exactly where the team’s effort is going, and the team feels credited for all the crucial, sometimes unglamorous, work they do to maintain quality and set the stage for future innovation. By defining these terms clearly and consistently, we move past the confusing debates and into a state of high-velocity, low-blame, and high-trust development.
It’s time to take control of your backlog and stop letting the chaos of poorly defined work dictate your pace!