definition.tech_spike

A technical spike is a timeboxed investigation that answers specific architecture or implementation questions. Define the spike's background, questions to answer, and expected deliverables; set explicit success criteria; assign owners; and establish a work plan for backlog conversion. This reduces uncertainty before committing to large-scale design decisions.

A spike charter contains background on the problem, the specific questions you need answered, concrete deliverables you'll produce, evaluation criteria for success, and a timeboxed work plan with assigned owners. This structure ensures the spike stays focused and delivers actionable results for engineering planning and architecture reviews.

Use spikes when you face cross-team uncertainty about system scalability, technology risk, tooling constraints, or architectural feasibility. Spikes are most valuable before major implementation commitments, during architecture reviews, or when evaluating new frameworks or platforms to understand performance and cost implications.

Establish explicit evaluation methods and success definitions upfront. Outline what answers or data the spike must produce to inform the next decision, and specify how you'll measure whether the spike answered your core questions. This prevents scope creep and ensures the spike delivers value to backlog planning.

Yes. Frame the spike around concrete questions: for GraphQL, determine feasibility and performance impact; for serverless, understand performance implications and cost. Structure the spike charter with background on your current architecture, deliverables from the investigation, and criteria for deciding whether to adopt.

A spike investigates and de-risks a question before implementation; it produces knowledge and evaluation criteria, not production code. A backlog item builds a feature. Spikes feed into backlog planning by reducing uncertainty about what to build and how, enabling better estimates and architecture decisions.