Every so often in sprint planning, a story lands that nobody can point. Estimates range from a 2 to a 13, someone says “well, it depends”, and the discussion goes in circles. Should we use GraphQL or REST? Can the system actually handle 10,000 concurrent users? Is this third-party library production-ready? You can’t estimate your way out of questions like that. You have to go and find out. That’s what a spike is for.

Where spikes come from

#

The term is from Extreme Programming, where it meant a “very simple program to explore potential solutions” — driving a spike through the problem. The modern version is a short, time-boxed research task whose output is knowledge, not working software. A spike isn’t a user story and delivers no customer value on its own, and that’s fine. Its job is to answer one specific question so the real work can be estimated and planned honestly.

In practice they come in two flavours. Technical spikes explore the how: evaluating a framework or library, prototyping an architectural pattern, performance-testing under realistic conditions, or finding out how painful an integration will really be. Functional spikes explore the what: clarifying an ambiguous story, testing a UI idea with a throwaway prototype, or poking at domain complexity until it makes sense.

Why they’re worth the time

#

Trying to estimate work with big unknowns gives you one of two things: padded estimates or missed deadlines. A spike converts “no idea” into actual data, so the team can commit to something with a straight face. It also replaces opinion wars with evidence — instead of arguing about which database is better, you spend two days measuring, and the findings feed straight into your decision documents.

Mostly, though, it’s cheap insurance. A two-day spike that reveals a library’s limitations costs far less than discovering the same limitation three sprints into development.

When a spike is (and isn’t) the right call

#

Reach for a spike when the team can’t confidently estimate a story because of technical unknowns, when several viable options exist and you need data to pick one, when you’re considering a new technology or integration, when performance is both uncertain and critical, or when requirements stay ambiguous no matter how many stakeholder meetings you sit through.

Don’t use one for work the team already knows how to do, or as a way to delay a decision you could make with the information you have. And a spike is not a substitute for proper requirements gathering or user acceptance testing — it answers a question, it doesn’t validate a product.

How I run one

#

Start by writing down the question. Not “research caching” but “can a Redis cluster meet our 50ms latency requirement?” Give it explicit scope — what’s in, what’s out — a time-box of one to three days (if it needs more, the question is too broad), and success criteria so you’ll know when you’re done.

Then investigate: read the docs and case studies, build a minimal proof of concept, talk to people who’ve done it before, and measure things with real code. Spike code is disposable by design.

When the time-box ends, write up findings, a recommendation with the reasoning, and any risks you uncovered, with links to the prototype clearly marked as spike output. Present it to the team, take questions, and adjust the backlog — create, refine, or kill stories based on what you learned. It’s also worth reflecting on how the spike itself went in your next retrospective; teams get noticeably better at spiking with practice.

The template I use

#

## Spike: [Title]

**Time-box**: [X days]
**Owner**: [Name]
**Sprint**: [Sprint number/name]

### Question to Answer
[Single, focused question this spike will answer]

### Background
[Why this spike is needed; what triggered the uncertainty]

### Assumptions
- [Assumption 1]
- [Assumption 2]

### Scope
**In Scope**:
- [Item 1]
- [Item 2]

**Out of Scope**:
- [Item 1]

### Success Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]

### Findings
[To be completed during spike]

### Recommendation
[To be completed after spike]

### Follow-up Stories
- [ ] [Story 1]
- [ ] [Story 2]

The assumptions section earns its place. Writing down “our data model is primarily relational” and “reads will outnumber writes 10:1” before you start does two things: it lets people challenge your framing before you burn the time-box, and it means that if an assumption turns out to be wrong mid-spike, you’ve learned something valuable rather than wasted two days.

Ways spikes go wrong

#

The classic failure is scope creep — the spike quietly becomes an open-ended research project. When new questions appear (they will), write them down as candidate spikes rather than expanding the current one. The second failure is goldplating: the moment you catch yourself adding error handling or tests to spike code, you’ve crossed from exploration into implementation. Third, skipping the write-up — six months later someone will face the same question, and your two days of learning will be gone. And finally, treating the spike as a commitment to a predetermined answer. A spike that proves an approach won’t work has done its job perfectly.

Fitting them into sprint planning

#

A few habits that have worked when planning sprints: if a story has real unknowns, spike it this sprint and schedule the actual work for a later one. Keep it to one or two spikes per sprint — more than that and focus evaporates. Don’t put story points on spikes; they produce knowledge, not software, so track them by their time-box. And present spike findings during refinement, before the team estimates the related stories, not after.

The next time a story generates more questions than answers, consider that a spike might be the most useful work in the sprint. Sometimes the fastest way forward is to stop and learn.

The short version

#

A spike is a time-boxed investigation, one to three days, into a single question the team can’t estimate its way past. It’s the right call when unknowns are what’s blocking the estimate: several viable options and no data to choose between them, a new technology or integration, performance that’s both uncertain and critical, or requirements that stay vague. It isn’t for work the team already knows how to do, or for putting off a decision you could make with what you already know.

What it produces is knowledge rather than software: findings, a recommendation with the reasoning, the risks you uncovered and a throwaway prototype. The backlog changes to match. Spikes get a time-box rather than story points, and the findings should reach refinement before anyone estimates the related stories.

Further Reading

#

Related Articles on This Site:

• Retrospectives: Reflecting on Spike Outcomes - Folding spike learnings into continuous improvement
• User Acceptance Testing - Validating that spike-informed decisions meet user needs
• Decision Documents - Structuring the decisions that come out of spike findings
• API Planning - How spikes can inform API design decisions

External Resources:

• Spikes - Scaled Agile Framework (SAFe) - The SAFe guide to spikes at scale
• Spike Solutions - Extreme Programming - The original XP concept
• The Scrum Guide - Where spikes fit into sprint planning
• Martin Fowler on Technical Debt - How spikes help prevent technical debt