Spike
A timeboxed research or experimentation activity used to reduce uncertainty about a technical approach or unknown, rather than to deliver a shippable Increment.
What it means
The term spike comes from Extreme Programming, not the Scrum Guide. It is used when a Product Backlog item cannot be estimated or planned confidently due to a significant unknown.
A spike is timeboxed, for example one or two days, and produces a decision, a prototype, or new information, not necessarily production code. The output feeds back into Refinement so the original item can then be estimated properly.
Common mistakes
Overusing spikes can mask a team's discomfort with uncertainty; they work best reserved for genuine unknowns, such as evaluating an unfamiliar third-party API, rather than routine research.
Example
The team timeboxes a two-day spike to test whether a new payment provider's API supports recurring billing before committing to the integration.