Spike Template for Agile Teams

One to two spikes per sprint is typical for a team of 5-7 people. More than that suggests the [backlog](/glossary/backlog) is not refined enough. If every story needs a spike, the team is starting sprints with too much uncertainty. Invest more in [backlog grooming](/templates/backlog-grooming-template) to resolve questions earlier.

Spikes should be estimated in time (hours or days), not story points. Story points measure deliverable work. A spike delivers knowledge, not a shippable increment. Track spike time separately in your [capacity allocation](/templates/capacity-allocation-template) under the experimentation or discovery bucket.

A spike answers a specific question. A prototype demonstrates a potential solution. A spike might produce a prototype as evidence, but the prototype is a means to an end, not the end itself. If the goal is to test an idea with users, that is a design spike. If the goal is to evaluate a technology, that is a technical spike. Both may involve building something throwaway.

Yes. PMs should request spikes when they need technical or design information to make product decisions. "Is it feasible to integrate with this API?" and "Will this interaction pattern work on mobile?" are both valid PM-initiated spike questions. The PM defines the question and success criteria. The engineer or designer runs the investigation.