Technical Spikes: When to Investigate Before Estimating

Teams do not always have enough information to estimate. When uncertainty is technical, the answer is not to guess — it is to investigate. That is exactly what a technical spike is for.

What Is a Spike

A spike is a timeboxed investigation task. The goal is not to ship production code, but to gain enough knowledge to estimate and plan the real work.

“2-day spike to investigate whether the partner API supports webhooks.”

When to Use a Spike

New Technology

“We have never used GraphQL. A 2-day spike to evaluate whether it is worth migrating to.”

Unknown Integration

“We do not know if this payment gateway supports our architecture. A 1-day spike to test the sandbox.”

High Technical Risk

“We need to process 1M records in < 5s. A spike to test whether Redis is sufficient or if we need a different approach.”

Multiple Possible Solutions

“We could use ElasticSearch, Algolia, or Postgres full-text search. A 3-day spike to compare all three.”

How to Define a Spike

Fixed Timebox

A spike always has a defined maximum duration. 1-3 days is most common. If the time runs out and the answer is incomplete, the spike outputs whatever it has and the team decides whether to run another spike or estimate with the remaining uncertainty.

Clear Objective

“Find out whether API X supports Y and what the cost per request is.”

Not “study API X” — it must be specific and verifiable.

Defined Output

The output of a spike is knowledge, not code:

• Documented findings
• Proof of concept (throw-away code)
• Recommendation on whether to proceed
• Refined estimate for the main task

Estimating a Spike

Spikes are estimated in time, not story points:

“This spike will take 2 days” because it is an investigation effort with a fixed deadline.

The spike’s results then enable the team to estimate the actual work in story points.

End-to-End Flow

1. Identification: “We do not have enough information to estimate this task”
2. Create the spike: Define objective, timebox, and expected output
3. Execution: Team member(s) investigate within the timebox
4. Result: Documented findings or knowledge-sharing session
5. Re-estimate: Team plays Planning Poker with the new information

Practical Example

Scenario

The PO wants “push notifications on mobile.” The team has never implemented this before.

Without a Spike

The team guesses: “8 points.” Implementation reveals: Firebase, APNs certificates, iOS fallback, rate limiting… It balloons to 21 points. The sprint is late.

With a Spike

• Spike: 2 days, objective “evaluate push notification options for iOS and Android and estimate effort”
• Findings: Firebase Cloud Messaging (free), APNs for iOS (certificate complexity), backend needed to manage tokens
• Post-spike estimate: 13 points with high confidence
• Result: correct planning, sprint delivered on time

Spike Anti-Patterns

Spikes Without a Timebox

“A spike to study Kubernetes” with no fixed deadline becomes productive procrastination.

Spike Code Becomes Production

Spike code is throw-away by design. If it goes into production, you are shipping something that was rushed together during an investigation.

Too Many Spikes

If more than 20% of tasks require spikes, the team lacks sufficient domain or codebase knowledge.

Conclusion

Technical spikes are the agile way of saying “we do not have enough information” without coming across as incompetent. They are an investment in information — and good information produces good estimates, which produce good planning. A 2-day spike prevents a 10-day sprint from going in the wrong direction.