Should spikes have story points?

No. A spike is a time-box, not a story. The number on the card is a budget.

A spike's deliverable is knowledge — a doc, a prototype, a recommendation, a measurement — not shipped product code. You can't size knowledge against the reference story because the reference story is feature work and the spike is research. The team that votes on a spike is voting on what they hope to find, which produces the same answer every time and means nothing.

Two practical handlings, both reasonable:

Option 1: Hours, not points

Vote on the time-box itself: "this is a half-day spike", "this is a two-day spike". The output is a budget, not a Fibonacci value. When the spike comes back with a result, the actual story it informed gets pointed like any other story.

Option 2: Off the velocity number entirely

Some teams keep spikes off velocity completely — they're investment, not delivery, and conflating the two distorts the planning signal. The team budgets a fraction of capacity for spikes (say, 15%) and accepts that velocity reflects only the delivery work.

Either approach works. Picking one and applying it consistently does. The wrong move is to vote story points on a spike — that's the worst of both worlds: a number that doesn't represent effort and a velocity signal that lies.

If the team really wants a points value, vote on the next story — the one the spike's output enables.

See: what is a spike for the broader definition; worked example of estimating one.