It depends on what you want velocity to measure. If velocity should reflect all the work the team can do in a sprint, give bugs and tech debt story points like any other item. If velocity should reflect new value delivered, don't point bugs (especially ones the team created) and instead reserve capacity for them. Both are defensible; what breaks forecasting is mixing the two, or switching between them without telling anyone.
Below are the strongest arguments on each side, a decision table for bugs, tech debt, spikes and tiny fixes, and a worked example showing how to plan with either approach.
Camp 1: Give bugs and tech debt story points
The argument: story points estimate the size of work. A bug fix that takes the team three days of investigation, fixing and regression testing consumes the same capacity as a three-day feature. If you don't point it, velocity looks like it dropped for no reason, and capacity planning undercounts what's in the sprint.
What this camp gets right:
- Sprint planning sees all the work, so the team doesn't overcommit.
- One backlog, one scale, one velocity number. Simple.
- Tech debt work becomes visible with a cost attached, which helps the PO prioritize it against features.
- Large bugs and refactors benefit from the same conversation as features: planning poker surfaces "wait, this touches the billing module" just as well for a bug.
Where it goes wrong:
- Velocity can rise while useful delivery falls. A team that ships bugs and then points the fixes gets "credit" twice.
- Stakeholders reading the velocity chart can't tell feature work from cleanup unless you label it.
- Bugs are often hard to size until you know the cause. "Sometimes users can't log in" could be 2 points or 13.
Camp 2: Don't point bugs; reserve capacity instead
The argument: velocity is a forecasting tool for the product backlog. Forecasting asks "when will these features be done?" Bugs are failure demand: rework on something that was supposed to be done already. Pointing them inflates velocity without moving the roadmap. Instead, leave unpointed capacity for bugs and let the slower feature velocity show the true cost of quality problems.
What this camp gets right:
- Velocity stays tied to new value, so release forecasts are more honest.
- Rising bug load shows up as falling velocity, which is the signal you want. Nobody can hide quality problems behind a stable number.
- Less time spent estimating unpredictable work.
- Bugs found in the current sprint's own stories aren't new work at all; the story simply isn't done yet under your Definition of Done.
Where it goes wrong:
- If bug volume swings, a fixed reservation is either too big or too small.
- There's no data on how much maintenance actually costs unless you track time or counts separately.
- Large planned refactors are real, chosen work. Leaving them unpointed makes them easy to deprioritize forever.
Where both camps agree
- Bugs in this sprint's own stories don't get separate points. If a tester finds a defect in a story still in progress, that's part of finishing the story.
- Tiny fixes aren't worth estimating. A typo or one-line config change takes less time to fix than to discuss.
- Be consistent and document it. Write down in your team working agreement what velocity includes. If someone reads your velocity chart, they should know.
- Size relative to the same baseline. If you do point maintenance work, a 5-point bug should be about as much work as a 5-point feature. Complexity doesn't change because of the ticket type.
Decision table: what to point
| Work item | Recommendation | Why |
|---|---|---|
| Defect found in a story still in the sprint | Don't point; it's part of finishing the story | The story isn't done until it meets the DoD |
| Tiny fix (under about an hour, obvious cause) | Don't point; fix it, optionally count it | Estimating costs more than doing |
| Escaped bug from a past sprint, cause known | Point it if you use Camp 1; otherwise take from the bug reservation | Planned work with knowable size |
| Bug with unknown cause | Timebox an investigation first (spike), then point or reserve the fix | You can't size what you don't understand |
| Production incident / urgent fix | Don't point in advance; handle from reserved capacity; record time afterwards | It interrupts the sprint regardless of estimates |
| Planned refactor or upgrade (tech debt) | Point it and label it "tech-debt" | It's chosen work competing with features for capacity |
| Spike / research | Timebox in hours or days, don't point | Output is knowledge, not a shippable increment |
| Infrastructure / CI improvements | Point and label "infra" | Planned work; labels keep feature velocity readable |
Pick your approach
| If your situation is... | Then... |
|---|---|
| Small team, one backlog, bug load fairly steady | Camp 1: point everything over an hour, label by type |
| Stakeholders forecast feature delivery from velocity | Camp 2, or Camp 1 with separate feature velocity for forecasting |
| Bug arrival is spiky and unpredictable | Reserve capacity for unplanned work; point planned tech debt only |
| Large legacy codebase with a big defect backlog | Point the defect backlog like features; treat it as planned work the PO prioritizes |
| Regulated or audited environment that tracks defects separately | Keep bugs on their own track, but count their effort in capacity planning |
| You can't agree as a team | Run Camp 1 with labels for 4-6 sprints, then look at the data together |
Worked example: same sprint, two approaches
A team has 5 sprints of history. They label every completed item by type.
| Total points | Features | Bugs | Tech debt | |
|---|---|---|---|---|
| Sprint 1 | 38 | 28 | 6 | 4 |
| Sprint 2 | 41 | 30 | 8 | 3 |
| Sprint 3 | 36 | 22 | 11 | 3 |
| Sprint 4 | 40 | 29 | 5 | 6 |
| Sprint 5 | 39 | 27 | 7 | 5 |
| Average | 38.8 | 27.2 | 7.4 | 4.2 |
Approach A (point everything). Plan to about 39 total points, including roughly 7 points of known bugs and 4 of tech debt from the backlog. For roadmap forecasting, use feature velocity, about 27 points per sprint, not the total. A 135-point feature epic is roughly 5 sprints, not 3.5.
Approach B (reserve for bugs). Bugs averaged 7.4 of 38.8 points, roughly a fifth of the sprint. Plan 31-32 points of pointed work (features plus tech debt) and leave the rest unplanned for bugs as they arrive. Velocity reported to stakeholders is now around 31.
Either way, the feature forecast is about the same. What changes is the number on the chart, which is why documenting your choice matters more than the choice itself. Sprint 3 is also worth noticing: bug points nearly doubled. Under Approach A you'd see that in the "Bugs" column; under Approach B it would show up as feature work squeezed out. Both make the quality problem visible if you look.
Use the sprint velocity calculator for the averages, and see how to calculate team velocity for handling outliers like Sprint 3.
Estimating bugs and tech debt well
Include the whole job. For a bug: reproducing it, finding the root cause, the fix, regression tests and verification after deploy. For tech debt: the change, migrating callers, and testing that nothing broke. Estimating only the coding is why maintenance work overruns.
Split investigation from fixing. When the cause is unknown, use a timeboxed spike ("half a day to find the cause of the login failures"), then estimate the fix. Trying to point a mystery leads to wildly spread votes. If the team's planning poker round on a bug shows 2, 3 and 13, that spread usually means some people have a theory about the cause and others don't.
Make tech debt concrete. "Clean up the payments code" can't be estimated. "Extract card-tokenization into its own module and move the three callers to it" can. Write tech debt items with the same acceptance criteria as features: what's different when it's done?
Use confidence, not padding. Bugs carry more uncertainty than features. Rather than quietly adding points, say it out loud. Alignlee attaches a 0-100% confidence slider to each vote, so a bug everyone sizes at 5 with low confidence is a visible cue to spike it first. See confidence voting in planning poker.
Common anti-patterns
| Anti-pattern | Problem | Fix |
|---|---|---|
| Inflating bug estimates to "prove" quality is bad | Estimates stop meaning size | Report bug counts or the bug share of velocity directly |
| Pointing bugs but not refactoring (or the reverse) | Inconsistent velocity; one type of work looks free | Apply one rule to all non-feature work |
| Every bug is "1 point" | Hard bugs blow up the sprint | Estimate by actual size, or spike first |
| Velocity chart with no legend | Stakeholders misread a bug-heavy sprint as a slowdown | Label work types; show feature velocity separately |
| Tech debt always deferred | Work slows gradually as debt grows | Reserve a regular slice of each sprint, or put tech debt items in the ordered backlog with points |
| Re-pointing a bug mid-sprint to match time spent | Points turn into hours | Leave the estimate; discuss the miss in the retro. See re-estimating stories mid-sprint |
Explaining it to stakeholders
When velocity dips, use the labelled data:
"Velocity was 36, about normal. 11 of those points went to customer-reported checkout bugs and 3 to planned tech debt, so feature delivery was 22 instead of our usual 27. We've added a regression test suite for checkout to the next sprint to bring that back down."
That framing protects the team from "why did you slow down?" pressure without fudging estimates. More on that in handling management pressure on estimates.
FAQ
Should bugs have story points?
Point bugs if you want velocity to reflect all the work the team does; don't if you want it to measure new value and prefer to reserve capacity for bugs. Either works as long as you're consistent and document it. Most teams agree that defects found in stories still in progress, and tiny fixes, shouldn't get separate points.
How do you estimate technical debt?
Turn it into a concrete item with a clear end state and acceptance criteria, then estimate it with the same story point scale and reference stories as features. Include migration and regression testing in the size. If the scope is unclear, run a timeboxed spike first.
Should story points be given to bugs found during the sprint?
Not if the bug is in a story that's still in the sprint. That's part of finishing the story under the Definition of Done. Bugs in work already released in earlier sprints are new work and can be pointed or taken from reserved capacity, depending on your team's approach.
Do spikes get story points?
Usually not. A spike's output is knowledge rather than a shippable increment, so most teams timebox it in hours or days instead. The follow-up work the spike uncovers is then estimated in points as normal.
How much sprint capacity should go to technical debt?
There's no universal number. Look at your own history: label work by type for several sprints and see what share bugs and tech debt actually take. Then decide with the Product Owner whether to keep that share, raise it to pay debt down, or lower it, and make that a visible, recurring part of sprint planning.