Agile Alliance Sizing Spikes
Source identity:
ddx:
id: resource.agile-alliance-sizing-spikesAgile Alliance Sizing Spikes
Source
- URL: https://agilealliance.org/the-practice-of-sizing-spikes-with-story-points/
- Accessed: 2026-05-12
Summary
Agile Alliance published a practitioner discussion arguing that spikes are best handled as time-boxed learning work rather than as value-delivery work hidden inside velocity. The article frames a spike as work aimed at answering a question or gathering information instead of producing shippable product.
Relevant Findings
- A spike exists to answer a question or gather information.
- Time-boxing keeps uncertainty visible and limits open-ended investigation.
- Treating spike effort as normal delivery can obscure how much user value is actually being produced.
- Spike results should make planning and estimation more honest, not make progress metrics look better.
- Persistent spikes can reveal deeper design or technology uncertainty that needs direct attention.
HELIX Usage
This resource informs the Technical Spike artifact. HELIX uses it to keep spikes visibly separate from delivery work and to require a concrete learning result before design or build proceeds.
Authority Boundary
This resource is a practitioner article hosted by Agile Alliance. It supports spike framing and measurement hygiene, but it does not define HELIX planning policy or replace project-specific estimation rules.