What is a Spike?

A spike is a time-boxed research, investigation, or experimentation task used in agile software development to reduce uncertainty, gain knowledge, or explore technical feasibility before committing to a user story or feature. The term originates from Extreme Programming (XP), where it was coined by Kent Beck.

Unlike regular user stories that deliver working functionality to end users, spikes produce knowledge and information. The output of a spike is typically a decision, a proof of concept, a technical recommendation, or enough understanding to estimate and implement the related work with confidence.

The metaphor comes from a "spike" in rock climbing -- a temporary anchor driven into rock to gain a secure footing before proceeding with the climb. Similarly, a spike in software development provides the team with solid ground (knowledge) before proceeding with implementation.

In software development, teams frequently encounter situations where they lack sufficient knowledge to estimate or implement a piece of work. Common scenarios include:

• Unknown technology: the team needs to evaluate a new framework, library, or service they have not used before.
• Unclear requirements: the business need is understood at a high level, but the specific implementation approach is uncertain.
• Performance concerns: there is doubt about whether a proposed approach will meet performance requirements.
• Integration complexity: connecting with an external API or system whose behavior is not well documented.
• Architectural decisions: choosing between multiple possible architectural approaches for a new feature.
• Risk mitigation: validating that a proposed solution will actually work before investing significant development effort.

Without spikes, teams either avoid estimating uncertain work (leaving gaps in planning), pad estimates with excessive buffers, or start implementation and discover problems mid-sprint.

Technical Spikes

Technical spikes explore technology-related questions. They answer "Can we build this?" and "How should we build this?"

Examples:

• Evaluate three database options (PostgreSQL, MongoDB, DynamoDB) for a new microservice and recommend one based on query patterns, scalability, and operational complexity.
• Create a proof of concept for real-time WebSocket communication to determine if the existing infrastructure can support it.
• Test the performance of a new search library against the current implementation with realistic data volumes.
• Investigate whether migrating from REST to GraphQL would reduce the number of API calls for the mobile app.

Functional Spikes

Functional spikes explore user interaction, design, and requirement-related questions. They answer "What should we build?" and "How should users interact with it?"

Examples:

• Prototype two different checkout flow designs and conduct usability testing to determine which one users prefer.
• Research how competitors handle multi-currency pricing to inform the product requirements.
• Interview three customer support representatives to understand the most common user pain points with the current reporting feature.
• Create wireframes for a new dashboard and validate them with stakeholders before committing to full design and development.

Architectural Spikes

A subset of technical spikes focused specifically on system architecture decisions:

• Evaluate monolith vs. microservices architecture for a new product line.
• Investigate the feasibility of a canary release strategy for the payment processing system.
• Research event-driven architecture patterns for the notification system.

Time-boxed

Spikes must have a strict time limit. Without a time box, research can expand indefinitely (analysis paralysis). Common time boxes include:

• 1-2 days for simple evaluations or questions.
• 3-5 days (one sprint) for more complex investigations.
• Maximum 1 sprint: if a spike needs more than one sprint, it should be broken into smaller, focused spikes.

If the time box expires without a conclusive answer, that itself is valuable information -- it may indicate that the problem is more complex than anticipated, or that the approach needs to be reframed.

Goal-oriented

Every spike must have a clear, specific objective and defined deliverables. A well-defined spike answers a specific question rather than exploring a topic broadly.

Weak spike definition: "Research authentication options." Strong spike definition: "Compare OAuth 2.0, SAML, and API key authentication for our B2B API. Evaluate each on security, implementation complexity, and client developer experience. Deliver a recommendation with trade-offs by Friday."

Not directly deliverable

Spikes do not produce shippable product increments. Their output is information -- documents, prototypes, proofs of concept, recommendations, or decisions. This distinction is important for tracking and reporting: spikes should typically not count toward the team's velocity if velocity is measured in delivered story points.

A well-structured spike includes:

Title

A clear description of what is being investigated.

Objective

What question does this spike answer? What decision will it enable?

Context

Why is this spike needed? What uncertainty or risk does it address?

Approach

What activities will the team undertake? (e.g., build a prototype, read documentation, interview stakeholders, run performance tests)

Deliverables

What concrete outputs are expected? Examples:

• A written recommendation document with trade-offs.
• A working proof of concept in a branch.
• A decision recorded in an Architecture Decision Record (ADR).
• Updated estimates for the related user stories.

Time box

The maximum duration for the investigation.

Acceptance criteria

How will the team know the spike is done? For example:

• "The team can estimate the related stories with confidence."
• "A technology recommendation has been agreed upon by the team."
• "A working prototype demonstrates the integration with the payment API."

In Scrum, spikes are typically handled in the following ways:

Planning

Spikes are placed in the product backlog and prioritized like any other backlog item. They are usually prioritized ahead of the stories they unblock, often in the sprint before the related feature work is planned.

Estimation

There are different approaches to estimating spikes:

• Fixed time box: the spike is given a time box (e.g., 2 days) rather than story point estimate. This is the most common approach.
• Story points: some teams estimate spikes in story points, treating them like any other backlog item for planning purposes.
• No estimation: some teams do not estimate spikes at all, allocating a fixed percentage of sprint capacity to research.

Sprint Review

Spikes are demonstrated in the Sprint Review by presenting the findings, recommendations, and any prototypes created. While they do not produce shippable increments, the knowledge gained is valuable output that should be shared transparently.

In a Kanban system, spikes flow through the board like any other work item but are typically tagged with a different class of service or work type. Since Kanban does not have sprints, the time box for a spike is enforced by the team's discipline and policies. The key consideration is that spikes should respect WIP limits -- a spike in progress occupies a slot just like any other work item.

1. Keep them focused: each spike should address one specific question or uncertainty. If multiple unknowns exist, create separate spikes for each.

2. Define success criteria upfront: before starting a spike, agree on what "done" looks like. This prevents open-ended research.

3. Share the findings: the output of a spike should be documented and shared with the team, not kept in one person's head. A brief write-up, a lunch-and-learn, or an ADR ensures the knowledge is preserved.

4. Build the simplest possible prototype: if the spike involves building something, build the minimum needed to answer the question. Prototype code should be treated as throwaway -- it exists to learn, not to ship.

5. Involve the right people: complex spikes benefit from collaboration. A performance spike might need a backend engineer and a DevOps engineer; a UX spike might need a designer and a customer support representative.

6. Time-box strictly: when the time box expires, stop and evaluate what was learned. If more research is needed, create a follow-up spike with a refined scope.

7. Connect to the dependent work: clearly link the spike to the user stories or features it unblocks, so the team understands the purpose and priority.

• Perpetual spikes: spikes that keep rolling over from sprint to sprint without reaching a conclusion. This usually indicates the scope is too broad.
• Gold-plated prototypes: spending time making prototype code production-ready instead of focusing on answering the question.
• Skipping spikes: jumping straight into implementation despite significant uncertainty, leading to wasted effort and rework.
• Vague spikes: "Research X" without a specific question, time box, or deliverable. These rarely produce actionable outcomes.
• Using spikes to avoid estimation: creating spikes for work that is uncertain but estimable, delaying delivery unnecessarily.

Should spikes count toward velocity?

This depends on the team's approach. Some teams include spikes in velocity because they represent real work done during the sprint. Others exclude them because spikes do not deliver shippable functionality. The most important thing is consistency: pick one approach and stick with it so velocity remains a meaningful metric.

How many spikes should be in a sprint?

There is no fixed number, but a sprint dominated by spikes (more than 20-30% of capacity) suggests that the team may not have enough clarity for effective planning. If many spikes are needed, consider whether the product backlog needs better refinement upstream.

What if a spike does not answer the question?

That is a valid outcome. Document what was learned, why the question remains open, and what additional information would be needed. Then decide whether to create a follow-up spike with a narrower scope or accept the uncertainty and proceed with a risk-aware approach.

Can a spike result in production code?

Generally, no. The code produced during a spike is intentionally quick and dirty -- meant to explore, not to ship. If a spike validates an approach, the implementation should be done as a separate story with proper design, testing, and code review. However, some teams find that spike prototypes can be refactored into production code if the quality is acceptable.

Who should work on spikes?

Anyone on the team can work on spikes, not just the most senior engineers. Spikes can be excellent learning opportunities for less experienced team members, especially when paired with a more senior colleague. The key is matching the complexity of the spike with the skills needed to answer the question effectively.

What is the difference between a spike and a proof of concept (PoC)?

A spike is broader -- it can involve any research activity (reading documentation, interviewing users, benchmarking, prototyping). A proof of concept is a specific type of spike output: a minimal implementation that demonstrates that something is technically feasible. A spike might result in a PoC, but it might also result in a document, a recommendation, or a decision without any code.