Estimating a research spike
A spike isn't a story. Don't size it like one.
Spikes are time-boxes with deliverables — "spend two days, come back with a recommendation." The number on the card is a budget, not a forecast. Estimating a spike with the feature deck is the wrong tool: you don't know what you'll find, the relative-effort question doesn't apply, and the team will end up arguing about a number that doesn't represent anything.
The other failure mode is letting the spike eat the work. The team votes a 3, the spike runs for two weeks, nothing ships, and the original story is still unestimated. A spike has a clock and a deliverable. If both aren't on the ticket, you're not estimating a spike — you're approving an open-ended investigation.
What gets said in the room
Engineer: "I genuinely don't know what this is until I look."
PM: "What does 'done' look like? A doc? A demo?"
Lead: "Two days, then we re-estimate the real story with what you've found."
QA: "What happens if the spike says 'don't build it'?"
Questions worth asking before voting
- What's the time-box — half a day, two days, a week?
- What's the deliverable — a doc, a prototype, a recommendation, a measurement?
- Who reviews the output, and against what criteria?
- What happens if the answer is "don't build this"?
- Is this on the team's velocity, or off-cycle?
Some teams keep spikes off the velocity number entirely — they're investment, not delivery, and conflating the two distorts the planning signal. Either approach works; not picking one and applying it consistently doesn't.
Related: other estimation techniques for fuzzier work, common mistakes on letting investigation creep into the story. Open a session after the spike, not during.