The story is called "Integrate with the new payments provider." The cards come up: a 3, two 8s, a 13, and a 20. Someone played the question mark. The product owner asks the 3 and the 20 to explain themselves, and within a minute both have said a version of the same sentence: "well, it depends how their webhook retries work." Nobody in the room knows how their webhook retries work. Nobody has ever called this API. The documentation is a marketing page and a Postman collection from 2023.

You can re-vote. The numbers will drift toward the middle, the team will settle on an 8, and that 8 will mean nothing. It's not an estimate. It's a random number wearing a confident face, and in three weeks it will detonate quietly in the middle of a sprint.

The problem here isn't courage. Teams get told to "just commit to a number" as if the spread were a nerve issue, something a braver group would push through. It isn't. The spread is the honest output. The team lacks knowledge, and no amount of discussion inside that meeting will manufacture knowledge that doesn't exist in anyone's head. The honest move is to stop estimating and go get the knowledge. That's a spike.

What a spike is, and what it isn't

A spike is a timeboxed investigation whose deliverable is knowledge. You spend a fixed, small amount of time answering a specific question, and at the end you know something you didn't know before. Then you take that knowledge back to the original story and estimate it for real.

Two things a spike is not.

It is not "work on it until it's done." An open-ended research task is just a story with no acceptance criteria and no end, and it will happily eat a sprint. The timebox is the whole mechanism. When the time is up, you stop, whether or not you'd like another day. What you learned in the box is the deliverable, including "we learned this is harder than we thought," which is genuinely useful information.

It is also not a license to secretly build the feature. This one is sneakier because it feels productive. A developer starts investigating the payments API, gets some calls working, keeps going, and by Thursday there's a half-built integration with no tests, no review, and no design conversation behind it. Now the team is anchored to code that was never meant to survive. A spike answers a question. If you come back with a working feature instead of an answer, the spike failed, even though something got built. Especially because something got built.

The telltale signs a story needs one

Most stories don't need a spike. The signal you're looking for is a specific flavor of uncertainty: not "this is big" but "we don't know enough to say how big." A few reliable tells:

  • The estimates spread wildly, a 3 next to a 20, and the discussion doesn't narrow them because both estimators are guessing about the same unknown.
  • The phrase "well, it depends how X works" comes up, and nobody in the room can finish the sentence with facts.
  • The story touches a system nobody on the current team has worked in. The person who understood the legacy billing service left two years ago, and the code has been radioactive ever since.
  • There's a third-party API or library in the critical path that nobody has actually integrated. Reading the docs doesn't count. Docs describe the happy path; integrations live in the error handling.

One caution before you reach for a spike: make sure the uncertainty is technical, not editorial. If the estimates scatter because the story is vague, ambiguous, or three stories in a trench coat, that's a writing problem, and the fix is writing user stories that are easy to estimate, not a research task. A spike can't answer a question the story never asked.

Writing a spike that earns its timebox

A good spike has three parts, and teams routinely skip two of them.

First, a question. Not a topic, a question. "Investigate the payments API" is a topic, and topics are bottomless. "Can the payments API deliver webhook events reliably enough that we don't need a reconciliation job?" is a question, and questions have answers. If you can't phrase the spike as a question someone could answer yes, no, or "here's the trade-off" to, you don't know what you're investigating yet, and the spike will wander.

Second, a hard timebox. A day or two is right for most spikes. Rarely more. If someone argues the investigation needs a week, that's usually a sign the question is too broad and should be split, or that this is actually project-level discovery pretending to be a spike. The short box also forces good behavior: you don't build nice abstractions in eight hours, you go straight at the unknown.

Third, a concrete deliverable. Knowledge is the point, but knowledge locked in one person's head evaporates by the next planning session. Ask for something you can hold: a one-page summary of what was learned, a throwaway prototype that proves the risky call works, or a written decision ("we'll use their batch endpoint, the streaming one drops events under load"). The deliverable is what the team estimates from later. Make it boring and explicit.

Points, or a timebox on the board

Should spikes get story points? Teams argue about this more than it deserves, so here's the honest take: no. Give spikes a timebox and charge them to capacity, and keep them out of velocity.

The reasoning is simple. Points estimate effort toward shippable value, and your velocity is only useful for forecasting if it measures that. A spike delivers knowledge, not product. If you point spikes, your velocity number inflates in exactly the sprints where you shipped the least, which is the opposite of what a forecast needs. Worse, pointed spikes invite gaming: a struggling sprint sprouts research tasks to keep the number respectable.

So: a spike costs the team one person-day or two, you subtract that from the sprint's capacity when you plan, and the velocity chart never hears about it. Some teams point spikes anyway for tracking-tool reasons, and if your tooling truly forces it, fine, just exclude them from forecasting. But don't pretend research is velocity. It's an investment that makes the next estimate real.

How spikes go wrong

Three failure modes account for nearly every bad spike.

The never-ending spike. Friday arrives and the answer is "we need more time." Sometimes that's true; unknowns are unknown. Extend once, with a new, sharper question based on what the first box surfaced. Then stop. If two timeboxes haven't produced an answer, the answer is the uncertainty itself: this work is high-risk, plan for it accordingly, or descope the risky part. A third extension isn't research anymore, it's avoidance with a ticket number.

The spike that ships. The prototype worked, the deadline is close, and someone suggests "cleaning it up" instead of rewriting. Resist this with everything you have. Spike code was written in a day, without tests, by someone deliberately ignoring edge cases to get at one question. Throwaway means throwaway. Delete the branch if you have to. The knowledge survives; the code shouldn't.

Spiking everything. Once a team discovers spikes, there's a season where every story with a whiff of uncertainty gets one. Hold the line. Uncertainty is the normal condition of software work, and ordinary point estimates already price in ordinary unknowns. A spike is for the big structural unknowns, the ones where the estimate isn't imprecise but meaningless. If more than one story in ten is spawning a spike, the team is either working in genuinely uncharted territory or using research as a hiding place from commitment. Usually the second.

Let the cards tell you

You don't need a new ceremony to find spike candidates. Your estimation session already surfaces them, if you let it.

The question mark card in a planning poker deck exists exactly for this. It isn't an abstention or a shrug; it's a player saying "I can't price this, and I want the room to know why." Treat every ? as a prompt for one sentence: what would you need to know to vote? If the answer is a fact nobody has, you've found your spike question, already phrased.

The other signal is a split that survives discussion. First vote scatters, the outliers explain, second vote still spans 3 to 20. At that point the room has told you what it knows, which is not enough. Don't run a third vote hoping for convergence; you'll get it, and it will be social convergence, not informed convergence. Cut a spike with the open question as its title and move to the next story. Teams that do this in ScrumMastr often get through the rest of the backlog faster, because "we don't know, and here's the ticket that says so" is a decision, and decisions end debates. There's more on keeping rounds tight in how to run a planning poker session that doesn't drag.

Close the loop or you did it for nothing

The step teams forget: after the spike, bring the original story back to estimation. Same room, same cards, new knowledge. Someone gives the two-minute version of the findings, the deliverable is linked in the ticket, and you vote again.

Then watch what happens to the spread. The story that scattered from 3 to 20 comes back as a 5 and three 8s, and the remaining gap is a real conversation about approach instead of dueling guesses about webhook retries. That collapse is the whole return on the spike, and it's worth making visible: it teaches the team, viscerally, the difference between uncertainty you can discuss away and uncertainty you have to go look at.

If the spread doesn't collapse, that's information too. Either the spike answered the wrong question, or the story is hiding a second unknown. Both are cheaper to discover now, in planning, than in week two of the sprint. A spike costs you a day. A confident 8 that was secretly a 20 costs you the sprint, plus a retrospective where everyone politely avoids saying "we knew we didn't know."