Should bugs have story points?

Yes, with one exception: the bug whose nature is "you don't know what's in there yet."

A bug with a known cause and a clear fix is a story. It has acceptance criteria ("the form no longer accepts negative quantities"), a defined scope, and a reasonable size. Vote it like any other story. Putting it through the deck respects the team's velocity — bug work and feature work compete for the same capacity, and the velocity signal needs to reflect that.

A bug whose nature is exploratory — "investigate the data corruption issue", "figure out why p99 doubled", "we can't reproduce it but customers keep reporting it" — is a different shape of work. The fix isn't sized because the cause isn't known. Treating it as a story produces the wrong number every time, because the team is voting on what they hope to find rather than what's there. These belong on a time-boxed investigation track: spend a day or two looking, then come back with a real story for whatever you find.

Why some teams say "no points for bugs" (and why they're wrong)

The argument is "bugs are technical debt; we shouldn't be tracking velocity on debt." The problem is that velocity isn't graded — it's a planning signal. If 30% of capacity goes to bug work, you want to see that in the velocity number, not hide it. A team that pretends bugs are free runs out of capacity for new work and doesn't know why.

The exception, sized properly

For exploratory bugs, vote on the time-box, not the fix. Half a day, a day, two days. When the cause is named, the actual fix becomes a real story. Worked example.

Story points for bugs you can scope. Time-boxes for bugs you can't.

See estimating bugs at feature precision for the failure mode of treating exploratory bugs as if they have a known size.