A spike is a time-boxed research experiment. You pick a specific question your team can't answer yet, constrain the time (often 2–3 days), run focused investigation, then decide what comes next. That's it. No endless research cycles. No "we'll figure it out as we go."
The term comes from extreme programming. Back then, a spike was literal: a small piece of proof-of-concept code written to unlock uncertainty about a technical challenge. The metaphor stuck because it's accurate. Imagine driving a spike through the top layer of something, pulling it out, and then looking down to see all those hidden layers of complexity underneath. You get clarity without excavating the whole thing.
Today, spikes aren't just code. A spike can be a vendor evaluation, a user research session, a prototype conversation with your infrastructure team, or a feasibility check on an API integration. The format doesn't matter. The constraint does.
Why Spikes Work
Most teams estimate research the way they estimate feature work. "We'll need 40 hours to figure out if we can migrate to this database." Then halfway through, they're still researching. The scope keeps expanding. Someone finds an edge case. Another person wants to test one more scenario. Two weeks later, you've spent more time investigating than you would have spent just building.
A spike flips that. Instead of estimating research, you budget it. You say: "We have 2 days. Here's the one question we need answered by Friday. What's the minimum work required to answer it?"
Constraint forces focus. It kills the rabbit holes. And it gives you a forcing function to make a decision. At the end of day 2, you either know enough to move forward, or you know you need more time and can make that call deliberately.
How to Run One
Start with a hypothesis or a specific question, not a vague topic. "Can we integrate with Salesforce" is too open. "Can we authenticate users through Salesforce SSO within our current Spring Boot architecture without a third-party library" is a spike.
Assign one person or a small pair. Big research committees dilute focus. One developer, one designer, one product manager. Whoever has the best chance of answering that one question.
Set a hard stop. "We're doing this Tuesday and Wednesday. Friday morning, we report back." No extensions. If you need more time, that's a new conversation with the team.
During the spike, do only what answers the question. Don't build production code. Don't optimize. Don't document for future use. Write throwaway code if you need to. Read the docs. Run a prototype. Call the vendor. The only deliverable is an answer.
At the end, the spike owner brings back one thing: clarity on that specific question. "Yes, we can do it, here's how." Or "No, it won't work because of X." Or "Yes, but it requires us to do Y first." That's enough to unblock the team.
Where Spikes Go Wrong
People often treat spikes like open-ended research projects. They start without a clear question. "Let's spike on microservices" turns into three weeks of reading architecture blogs. That's not a spike. That's procrastination with a Scrum label.
Another mistake: running a spike and then ignoring the answer. The spike says "No, this won't work." The team nods, thanks the spike owner, and then proceeds as if the spike never happened. If that's the outcome, the spike wasn't focused enough or the question wasn't real.
Spikes also fail when teams use them to avoid decisions. "We're not sure how to approach this, so let's spike." Sometimes you don't need a spike. Sometimes you need to pick a direction and learn by building. Spikes are for genuine unknowns, not for indecision.
When a Spike Makes Sense
You're facing a technical constraint you've never hit before. You don't know if your current architecture can handle it. Two days to test it beats two weeks of guessing.
You're evaluating a vendor or tool and the documentation doesn't answer your specific use case. A spike with real data beats vendor claims.
You're about to commit significant time to a feature but there's a dependency or integration question that could change the whole approach. Spike it first.
You're in a Scrum team and the Product Owner is pushing a story that feels risky because of unknowns. Recommend a spike as a separate work item. It unblocks the team and gives the PO data for prioritization.
If the answer is already in your head or in your team's experience, you don't need a spike. You need a conversation.
The Real Payoff
Spikes aren't about perfect answers. They're about moving from "I don't know" to "I know enough." Enough to build. Enough to decide. Enough to stop spinning.
When you constrain research time, you stop overthinking. You focus on signal over noise. And you get back to what actually matters: shipping value.
If your team is dancing around uncertainty instead of answering it, a spike is your tool. Pick the question. Set the timer. Go find the answer. Then move.
One short email, every other Friday. Real-world Scrum lessons, no fluff. Unsubscribe anytime.