When Your Team Can't Estimate: Use a Spike Instead

Table of Contents

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.

Where spikes come from#

Why they’re worth the time#

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

How I run one#

The template I use#

Ways spikes go wrong#

Fitting them into sprint planning#

Further Reading#