Estimating bugs in scrum isn’t about debating whether you should. It’s about knowing how to do it well.
When bugs are estimated, the team gains a clearer understanding of the time and resources needed to fix them.
This foresight leads to more accurate sprint planning, better prioritization, and improved decision-making.
Yet, bug estimation can feel tricky, especially because some bugs are predictable, while others are complete mysteries.
In this post, we’ll skip the should-you-or-shouldn’t-you debate and focus on practical, proven ways to estimate both known and unknown bugs so your scrum team can stay predictable and deliver consistent value.
🐞 Why estimating bugs matters in scrum
Estimating bugs gives your team:
- Better predictability: Bugs take up sprint capacity, and sizing them avoids hidden work.
- Improved prioritization: Knowing the complexity helps decide what gets fixed first.
- Smarter planning: Teams can commit to realistic sprint goals without being blindsided.
The catch?
Not all bugs are created equal. Some are known, easy to understand and scope while others are unknown, where the cause and fix are unclear.
Your estimation approach should change depending on which type you’re dealing with.
📝 How to estimate bugs in scrum
Think of bugs like unexpected guests at a party.
Some you’ve met before, and you know exactly what they’re like and how to handle them. Others? They show up unannounced, and you have no idea what they want or how long they’ll stay.
In scrum, it’s helpful to group bugs into two broad categories: known bugs and unknown bugs.
1️⃣ Known bugs
Known bugs are the familiar faces in your codebase. Your team understands:
- What’s causing them
- How they behave
- How to fix them
These are relatively easy to handle during sprint planning.
How to estimate known bugs in scrum:
- Treat them like any other product backlog item.
- Use story points based on complexity and effort.
- Leverage past experience to forecast how long fixes typically take.
Because the team is already aware of the problem, estimating becomes straightforward, similar to sizing a user story.
This allows for more predictable sprints and gives developers a sense of confidence in their commitments.
2️⃣ Unknown bugs
Unknown bugs are the troublemakers. You don’t know the cause, the fix, or the ripple effects. They can:
- Derail sprints
- Frustrate developers
- Disrupt the flow of delivery
So how do you estimate something you don’t yet understand?
The short answer: You don’t, at least, not right away.
Instead, start with a Spike.
A Spike is a timeboxed research activity used to investigate the bug, uncover the root cause, and explore possible solutions.
Once the spike is complete, the unknown bug becomes a known bug, one that can now be estimated like any other backlog item.
Steps to handle unknown bugs in scrum:
- Create a spike and add it to the sprint.
- Investigate until the cause is understood.
- Once known, estimate the fix in story points.
- Schedule it into a future sprint with confidence.
Known vs. unknown bug estimation – Quick reference
| Bug Type | What You Know | Estimation Approach | Tool/Method |
|---|---|---|---|
| Known Bug | Cause, scope, and fix are clear | Story points | Standard backlog item |
| Unknown Bug | Cause and fix unclear | Spike first | Timebox investigation |
Key takeaways for scrum masters
- Estimate bugs to make invisible work visible.
- Use standard story point estimation for known bugs.
- For unknown bugs, don’t guess. Run a spike first.
- Treat estimation as a tool for transparency and predictability, not just a number game.
📌 Conclusion: Bug estimation in scrum
Dealing with bugs, both known and unknown, is part of the scrum journey.
- Known bugs give teams a chance to refine processes and improve problem-solving.
- Unknown bugs push teams to investigate, innovate, and collaborate.
It’s not just about fixing code. It’s about evolving as a team, boosting capabilities, and delivering value without unpleasant surprises.
Next time a bug appears, ask yourself: Do we know enough to estimate this right now? If yes, give it story points. If not, spike it, then size it.
Your sprints and your sanity will thank you.
Here’s my post on whether to timebox or estimate spikes you should read.
I hope you found this post helpful.
