Spike (Agile)
A time-boxed investigation used when a story cannot be estimated or designed without further research or prototyping.
Definition
A spike is a time-boxed investigation in agile development, used when a story cannot be reasonably estimated, designed, or committed to without first doing focused research, prototyping, or spike-solution work. The term comes from Extreme Programming (Kent Beck), borrowed from the mountaineering metaphor of driving a spike into the rock face to test whether it will hold. A spike is not a story to be delivered — it is a story to be learned from. The deliverable is knowledge (usually a written finding, sometimes a discardable prototype), not shipped software.
When to Use One
- The team cannot size a story because the technical approach is unknown.
- A new integration or API is untested.
- A performance concern needs a proof-of-concept load test.
- A design choice between two architectures needs benchmarking.
- Regulatory or security review requires exploratory analysis.
How a Spike Should Be Written
- Time box: e.g. "2 engineer-days" or "one 3-day sprint slot". Non-negotiable.
- Question: precisely what will be known at the end.
- Deliverable: usually a written brief and, optionally, a throwaway prototype.
- Acceptance: the team can now size (or reject) the follow-on story.
"Investigate performance" is not a spike; it is a wish. "Determine whether the search endpoint can handle 500 requests/second under our current schema, in 2 engineer-days, delivering a written recommendation" is a spike.
Real-World IT / Agile Example
A team was asked to add real-time chat to an existing web app. The product owner wanted an estimate. The team refused to size until they had done a two-day spike comparing three approaches: extending the existing REST API with polling, adopting WebSockets on their current stack, or introducing a managed real-time service. The spike produced a two-page recommendation, a throwaway prototype of option 2, and a solid estimate for the delivery story. Without the spike, the team would have committed to a number roughly half of what the actual work took. With the spike, they delivered on time.
Real-World Construction Example
The construction equivalent is a test panel or mock-up. Before committing to a façade approach on a high-rise, the contractor builds a full-scale mock-up of one bay: fixings, glazing, insulation, waterproofing, tested for wind and water penetration. The mock-up is destroyed afterwards; its deliverable is knowledge — will the design work? what tolerances are achievable? — not the finished façade. Same discipline as a software spike: a time-boxed, cost-boxed learning exercise ahead of the main commitment.
Categories
- Technical spike — investigating a technology or design choice.
- Functional spike — exploring user needs or user experience.
- Risk spike — de-risking a known unknown before the main commitment.
Expert Tips
- Hard time-box the spike. If two days are not enough, that is a finding — not a reason to extend.
- Prototype code from a spike is not production code. Delete it. If it is genuinely useful, rewrite it properly.
- Produce a written finding. Verbal spike results are lost to memory in three weeks.
- Include stakeholders in the read-out. The whole point of a spike is to inform a subsequent commitment; the people making that commitment need to see the findings.
- Do not use spikes to sneak in refactoring. If refactoring is needed, put it in a normal story.
Common Mistakes
- Unbounded spikes that turn into feature work by stealth.
- Spike results not documented, so the learning is lost.
- Spikes that answer the wrong question — the team explored technology X when the real risk was integration Y.
- Treating spikes as a permanent alternative to estimating; teams that live in "we can't estimate anything without a spike" have deeper problems.
- Not deleting throwaway spike code — it ends up in production, unmaintained.
Practical Lessons Learned
- The best signal that a team's estimation is healthy is that they use spikes sparingly and precisely — for genuine unknowns, not as a shield.
- A two-page written spike finding, with a clear recommendation, is one of the highest-return artefacts a team can produce.
- Product owners who trust the spike process (and pay for the two days) are rewarded with much more reliable delivery estimates.
Key Takeaways
- A spike is a time-boxed learning exercise, not a delivery story.
- The deliverable is knowledge, ideally a short written finding.
- Hard time-boxes are essential; unbounded spikes are anti-patterns.
- Construction mock-ups follow the same design pattern for the same reasons.
Related Encyclopedia Entries
Related Research Articles, Case Studies & Tools
Frequently Asked Questions
Should spikes be estimated in story points?
Some teams estimate them, most simply time-box them. Story points measure effort to deliver; spikes measure effort to learn. Time-boxing is the more common and, in my view, cleaner approach.Can a spike span multiple sprints?
It shouldn't. If a spike needs more than one sprint, it is almost certainly the wrong question or the wrong time-box. Break it into two smaller spikes with clearer questions.Who does the spike?
Whoever can genuinely learn the answer — often one or two engineers, sometimes a mixed pair with a designer or security specialist. Never assign a spike to a junior engineer unsupervised; the whole point is decision-quality learning.What if the spike concludes the story is not feasible?
That is a successful spike. Killing an infeasible story after two days of investigation is far cheaper than discovering the same thing after four weeks of delivery. Product owners who understand this run their backlogs better.Is a spike the same as a proof-of-concept?
A proof-of-concept is one type of spike deliverable. Not every spike produces code — some produce a written recommendation, a benchmark, or an architectural sketch. All PoCs are spikes; not all spikes are PoCs.Do we ship the code from a spike?
No. Spike code is written to learn, not to maintain. Even when the pattern is right, the code is usually not clean, tested, or documented. If it looks worth keeping, write a proper story to build it again properly.How does this compare to construction mock-ups?
Very closely. Both are time-boxed, cost-boxed exploratory activities. Both produce knowledge, not the final product. Both are destroyed after they have taught what they need to teach. The disciplines transfer directly.What is a common misconception about Spike (Agile)?
That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.Which related encyclopedia entries should I read alongside Spike (Agile)?
Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.How does Dr. Hassan Eliwa's research treat Spike (Agile)?
Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Spike (Agile) is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.How is Spike (Agile) defined on PMMilestone Research & Insights?
A time-boxed investigation used when a story cannot be estimated or designed without further research or prototyping. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.
People also ask
Follow-up questions practitioners search for next — each one points to the calculator, template or reference entry that answers it.
Where is this in the glossary?
Quick-lookup definitions across 1,200+ PM terms. PM Glossary on PMMilestone.org ↗
Which learning track covers this end-to-end?
Structured tracks from beginner planner to programme controls director. Project Controls Academy ↗
Which book goes deeper than this entry?
Practitioner field handbooks with worked numerical examples. Books & Publications ↗
Which calculator on PMMilestone.org applies here?
The integrated EVM workbook covers most cost-schedule diagnostics. EVM Calculator ↗
Related Entries
More in Agile
- Letter AAcceptance Criteria
The specific, testable conditions a deliverable must meet before the customer accepts it — the contract between a team and the person who will sign off the work.
- Letter BBacklog Refinement
The ongoing practice of clarifying, splitting, estimating, and ordering items on a product backlog so the team always has a healthy queue of ready work for upcoming sprints or releases.
- Letter BBurn-Down Chart
A time-series chart showing remaining work against time, used by agile teams to visualise sprint or release progress and forecast completion.
- Letter CContinuous Integration
The engineering practice of merging code changes into a shared mainline many times a day and verifying each merge with automated builds and tests.
- Letter CCumulative Flow Diagram
A stacked-area chart of work items in each stage over time — the single most informative chart in lean and Kanban flow management.
- Letter DDaily Stand-up
A short, focused, time-boxed daily meeting where the delivery team aligns on progress, plans the next 24 hours of work, and surfaces blockers.
Further reading on PMMilestone.org
Curated companion resources hosted on the flagship platform, PMMilestone.org.
- For practitioners who want to go deeper, the Learning Tracks.
- Engineers researching this topic typically continue with the Books & Publications.
- A practical companion to this entry is the EVM Calculator.
- Closely related on the flagship platform is the Schedule Health Checker.
- Useful alongside this article is the PMMilestone.org knowledge hub.