Technical Spike
A technical spike is a short, time-boxed piece of research or experimental coding that a team does to answer a specific technical question before committing to the real work. Its output is knowledge, such as whether an approach is feasible or how long it will take, rather than production-ready code.
How Technical Spikes Work
The term comes from Extreme Programming (XP), where a spike solution is a very simple program written to explore a possible solution. The Scaled Agile Framework (SAFe) describes a spike as work that gains the knowledge needed to reduce the risk of a technical approach, better understand a requirement or increase the reliability of an estimate.
A useful spike has:
- One clear question, such as "Can our current database handle full-text search at our expected data volume?"
- A timebox, often a day or a few days, after which work stops regardless of progress.
- A visible result: a short write-up, a benchmark or a recommendation the team can act on.
Spikes are tracked as backlog items so their cost is visible. The code is usually thrown away; if the approach works, the team builds it properly as normal stories. Some teams distinguish technical spikes, about technology and implementation, from functional spikes, about how users should interact with a feature.
Why Technical Spikes Matter
Some work cannot be estimated because the team does not yet know how it will be done. Guessing produces unreliable plans, while open-ended research can swallow a sprint. A spike makes uncertainty explicit, caps what the team spends to reduce it and gives product managers better information for prioritization. It is the engineering counterpart to a prototype used in product discovery.
Technical Spike Example
A product manager wants to add bank-account syncing to a budgeting app, but nobody on the team has used the chosen bank-data provider. Instead of estimating the whole epic blind, the team schedules a two-day spike: connect to the provider's sandbox, pull transactions for one test account and note rate limits and error handling. The spike shows that the provider's update notifications are unreliable and regular polling is needed, which adds a background job to the design. The team then breaks the epic into stories it can estimate with confidence.