How to Estimate Spikes and Research Tasks

A spike is a timebox for learning: "We don't know enough to estimate this feature yet, so we'll spend time finding out." It's the standard answer when a story is too big or too vague to size. Estimating a spike is a different problem from estimating a known feature.

Don't estimate the outcome, estimate the timebox

The output of a spike is knowledge, not code. You can't estimate how complex the feature will be - that's what you're trying to find out. What you can do is decide how much time you're willing to invest before deciding what to do next.

Instead of "how hard is this?" the question becomes "how long will we spend on this?"

Two common timeboxing approaches

Fixed hours: "We'll spend 8 hours on this and report what we found." Simple, clear, easy to track.

Fixed sprint fraction: "This spike gets at most 20% of one developer's sprint." Keeps research work from expanding to fill the team's capacity.

What to produce at the end

Define the deliverable before the spike starts, not after. Common deliverables:

• A technical recommendation with trade-offs
• A proof-of-concept with known limitations documented
• A refined story with acceptance criteria, now estimable

Without a pre-defined deliverable, spikes become open-ended research projects.

When to use a spike

Use a spike when:

• The team can't agree on an estimate because the approach is genuinely unknown
• You need to evaluate external tools, APIs, or services
• Technical risk is high enough that prototyping is cheaper than a bad commitment

Don't use a spike as a way to defer estimation indefinitely. If the research is done and the team still can't size the feature, you need a different conversation.

A well-run spike reduces uncertainty. An open-ended one just delays it. (Teams practicing dual-track agile do this continuously, in a dedicated discovery track.)