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

The worst retrospectives I’ve sat through all had the same shape: we missed the sprint goal, so the whole hour turned into an inquest about the goal. The best ones barely mentioned the goal at all. We talked about how we’d worked, what got in the way, and what we’d try differently next time. That difference is what people mean by an outcome-independent mindset, and having run sprints myself for a while now, I think it’s the most useful attitude a Scrum Master can hold.

To be clear: results matter. Nobody pays us to have a lovely process and ship nothing. But delivering the sprint is the team’s job. The Scrum Master’s job is to improve the machine that delivers sprints. Those are different jobs, and mixing them up causes most of the dysfunction I’ve seen around Scrum.

Scrum Master vs project manager

#

The two roles get confused all the time, partly because plenty of companies hand both to the same person. The core difference:

Scrum itself has no project manager role. Much of what a project manager would usually do is split between the Product Owner, who decides what gets built and in what order, and the Developers, who plan how to build it.

What changes when you let go of the outcome

#

The team gets room to actually own things. Scrum is supposedly built on self-organising teams, but a Scrum Master who sweats every result ends up steering decisions, and the team quickly learns that decisions aren’t really theirs. Focus on process instead and you can let people experiment, make the occasional wrong call, and learn from it — which is the only way real ownership ever develops.

Retrospectives get honest. When the question in the room is “why did we miss the number?”, the true answers go into hiding. When it’s “what slowed us down, and what do we try next?”, people talk. The same goes for impediments mid-sprint: an outcome-obsessed Scrum Master panics about the deadline, while a process-focused one just gets on with removing the blocker, or suggests a time-boxed spike when the blocker is something nobody knows enough about yet.

Stakeholders calm down too. If the only story you can tell is the burndown chart, every wobble looks like failure. If you can also talk about what the team learned and how it’s adapting, expectations become more realistic — and the team gets shielded from a lot of pressure that would otherwise land on them halfway through a sprint.

If you’re already fixated on a result

#

Easier said than done, I know. When you’re deeply invested in something turning out a particular way, “just focus on the process” sounds like a fridge magnet.

A few things that actually help. First, don’t beat yourself up for caring — wanting a result is normal, and pretending otherwise doesn’t work. Second, translate the outcome goal into process goals you control: not “win the competition” but “practise 30 minutes a day”. You can’t control whether the release lands well; you can control whether it was reviewed, tested, and demoed early. Third, notice what’s feeding the fixation. If you’re refreshing a dashboard or a stock price ten times a day, pick set times to check and stop otherwise. And celebrate the small wins along the way, because the distant goal will happily eat all your attention if you let it. If the fixation is genuinely wrecking your sleep or your daily life, that’s worth talking to a professional about — no shame in it.

Results still matter. But the teams I’ve seen get them consistently are the ones where somebody is looking after the how, not just the what.