Definition
Spike
A spike is a time-boxed piece of investigative work used to reduce uncertainty before committing to a feature. Instead of producing shippable functionality, it produces knowledge — a prototype, a technical answer, or a risk assessment. The output is what the team learns, and the strict time-box prevents open-ended research from consuming a sprint.
Key takeaways
- A spike is a time-boxed investigation that reduces uncertainty before a team commits to building a feature.
- Its deliverable is knowledge — feasibility, an approach, a cost estimate — not shippable functionality.
- The strict time-box is the whole discipline: it turns open-ended research into a bounded experiment with a forced decision.
- A technical spike investigates how to build something; a functional spike investigates what to build.
The term comes from Extreme Programming. A spike exists for one reason: the team can't estimate or plan a piece of work because too much is unknown. Rather than guess, they invest a fixed, small amount of time to learn enough to plan confidently. The deliverable is information — feasibility, an approach, a rough cost — not a feature.
Two things make a spike a spike. First, it is time-boxed: 'spend two days finding out,' not 'figure this out.' The cap is the whole discipline — it converts unbounded research into a bounded experiment and forces a decision when the clock runs out. Second, its output is knowledge, often a throwaway prototype that is studied and then discarded rather than hardened into production code.
Spikes come in two flavors: a technical spike investigates how to build something (which library, which architecture), and a functional spike investigates what to build (how users would respond). Both end the same way — with a recommendation that lets the team estimate the real work and decide whether to proceed.
In Planoda a spike is simply an issue whose acceptance criterion is an answer rather than a shipped change, tracked in the same backlog and sprint as the work it de-risks.
Related terms
- Story Points (Estimation)Story points are a relative, unitless measure of how much effort an issue will take, accounting for complexity and uncertainty rather than raw hours. Teams estimate in points — often using a Fibonacci-like scale — to compare items against each other quickly. Summed across a cycle, points feed velocity and burndown without false precision about clock time.
- Backlog RefinementBacklog refinement is the ongoing practice of keeping a product backlog ready to work: clarifying items, splitting large ones, adding estimates and acceptance criteria, and re-ordering by priority. Often called grooming, it is continuous rather than a single event, ensuring the top of the backlog is always well-understood and small enough to be pulled into a sprint.
- Technical DebtTechnical debt is the implied future cost of choosing an easier or faster solution now over a better one that takes longer. Like financial debt, it accrues interest: shortcuts in code, architecture, or tests slow every future change until they're repaid through refactoring. Some debt is deliberate and strategic; some is accidental and corrosive.
- User StoryA user story is a short, plain-language description of a feature told from the user's perspective, classically in the form 'As a [role], I want [capability], so that [benefit].' It captures who needs something and why, deliberately leaving the how to the team. Stories keep work framed around user value rather than technical tasks.
- Definition of ReadyA definition of ready is a shared checklist a backlog item must satisfy before a team accepts it into a sprint. It typically requires that the item is clear, estimated, free of blocking dependencies, and has acceptance criteria. It is the entry gate to work, the mirror image of the definition of done, which is the exit gate.