Spike
A spike is a time-boxed investigation task designed to answer a specific question or reduce uncertainty before committing to full implementation. Unlike regular development work that produces shippable features, spikes produce knowledge - understanding of technical feasibility, estimation inputs, architectural options, or design approaches. The term comes from Extreme Programming (XP) and has become standard practice in agile development.
Why it matters
Development is full of unknowns. Sometimes teams don't know whether an approach will work, how long something will take, what dependencies exist, which technology to choose, or how to integrate with another system.
Starting full implementation with these unknowns is risky. Commitments might be impossible to meet. Work might need to be thrown away. Teams might go down dead ends. Estimates might be wildly wrong.
Spikes matter because they convert unknowns into knowns before significant resources are committed.
Types of spikes
Technical spikes explore technical questions: Can we integrate with this API? Will this library work for our use case? What's the performance of different approaches? How do we implement this algorithm? What infrastructure do we need? The output is technical findings, proof of concept, and recommendations.
Functional spikes explore design and user experience questions: How should users interact with this feature? What workflow makes sense? What edge cases exist? How do we handle this user need? The output is design options, mockups, and workflow diagrams.
Research spikes explore external knowledge: What are industry best practices? What have others done for this problem? What tools or services exist? What are the compliance requirements? The output is research summary, options analysis, and recommendations.
Spike characteristics
Time-boxed means spikes have fixed durations - typically a few hours for small questions, 1-2 days for moderate investigations, and rarely one sprint for complex explorations. When the timebox ends, the spike ends - even if more questions remain. Additional spikes can be planned if needed.
Goal-oriented means spikes answer specific questions, not open-ended exploration. "Determine whether we can use ElasticSearch for our full-text search requirements and estimate integration effort" is a good spike goal. "Learn about search technologies" is poor. Clear goals prevent spikes from becoming indefinite research projects.
Outcome-focused means spikes produce actionable outputs: decision recommendations, estimation inputs, technical documentation, proof-of-concept code (meant to be thrown away), and risk identification. The output should enable decisions or inform subsequent work.
Running effective spikes
Before the spike, define the question clearly - what specifically do you need to know? Set success criteria - what would a successful spike accomplish? Timebox appropriately - how much time is the answer worth? Assign appropriately - who has the skills to investigate effectively?
During the spike, stay focused on the question at hand rather than tangential interests. Document as you go by capturing findings in real-time. Communicate progress, and if the spike reveals the question was wrong, surface that early. Stop when answered - if the question is answered before the timebox ends, you're done.
After the spike, present findings by sharing what was learned with the team. Make recommendations about what we should do based on this knowledge. Update backlog by creating or refining stories based on spike learnings. Dispose of spike code because proof-of-concept code isn't production code; it either gets rewritten or discarded.
Spikes in sprint planning
Spikes are typically included in sprint backlogs when they're prerequisites for upcoming stories, when estimation requires spike findings, or when technical decisions block progress.
Some teams don't estimate spikes since output isn't user value. Others estimate using the same system as other work. Both approaches work if applied consistently.
Some teams reserve spike capacity - 10-20% of sprint capacity for spikes and exploration, an explicit spike quota per sprint, or flexible allocation based on uncertainty level.
Spike patterns
Pre-sprint spikes run before the sprint where work will occur. Sprint N includes a spike on search implementation approach; Sprint N+1 implements search based on spike findings. This ensures estimation and planning benefit from spike knowledge.
Parallel spikes have multiple team members investigate different options. Person A evaluates the vendor solution while Person B evaluates the open-source alternative, then they compare findings and decide.
Cascading spikes occur when an initial spike reveals the need for deeper investigation. Spike 1 asks which search technology we should use. Spike 2 asks how we implement ElasticSearch in our architecture. Then the story implements the search feature.
Repeated spikes address domains requiring ongoing exploration - regular competitive analysis spikes, periodic technology landscape reviews, or recurring compliance requirement updates.
Spike anti-patterns
Infinite spike describes research that never ends, continuously expanding scope. The timebox is the cure - when time ends, the spike ends.
Spike theater goes through spike motions when the answer is already known or the decision already made. If there's no genuine uncertainty, skip the spike.
Gold-plated spike happens when spike code becomes production code. Spike code is meant to answer questions quickly; production code has different requirements.
Unfocused spike investigates "technology X" without specific questions. This produces vague findings without actionable conclusions.
Hidden spike is research done during regular stories without explicit timebox or knowledge-sharing. This produces inconsistent approaches and lost learnings.
Spikes and product management
Product managers encounter spikes in several ways. Requesting spikes happens when decisions require technical input and PMs may request spikes to inform product direction. Accepting spike outcomes means incorporating learnings into product decisions when spikes reveal constraints or options. Prioritizing spikes recognizes that spikes compete for capacity, and PMs help determine when uncertainty reduction is worth the investment. Connecting to user needs ensures good spikes investigate questions that matter for user value, not just technical curiosity.
Tools like Klero help product managers identify where spikes might be valuable. When customer feedback reveals uncertainty about how to solve a problem, or when requests exceed current technical understanding, spikes may be the right response - and having clear customer context helps define spike goals effectively.
