A spike is a backlog item whose output is knowledge, not working software. You add a spike when the team can't estimate a story because they don't know enough to reason about it — and the cheapest way to get that knowledge is to spend a bounded amount of time finding out.
Two types:
Technical spike — exploring implementation options. "Which third-party payment API should we use and how long would integration take?" The output is a recommendation and a rough estimate, not production code.
Functional spike — clarifying business needs or UX direction. "What do users actually do when they encounter this error state?" The output is an insight that shapes the requirement, not a feature.
A spike without a clear question is just an open-ended research project. Before starting, the team should agree: what will we know by the end of this spike that we don't know now? What will we do with that knowledge?
Time-boxing is non-negotiable. Two days, one sprint, one week — pick an appropriate limit and commit to it. At the end, the spike closes. Whatever was learned gets integrated; whatever wasn't answered gets scoped into additional work if necessary.
I've used spikes most often at the start of a project to scope a new technical domain, or when a stakeholder asks "how long would it take to build X?" and X involves technology the team has never touched. A spike is the honest answer: "We don't know yet. Give us three days to find out."
Exam tip: Spikes reduce uncertainty before commitment — they don't replace refinement. A story that needs a spike before it can be estimated is not ready for the Sprint Backlog. The spike comes first.