spike

To create a time-boxed spike ticket, you define a hypothesis, set an explicit effort budget, and establish kill criteria for early stopping. This structured approach ensures fast technical de-risking for uncertain engineering questions like integration feasibility.

A hypothesis-driven engineering spike is a time-boxed exploration ticket that captures a specific question using a 'We believe X, we will know we are right when Y' format. Use it to evaluate scalability or migration viability when production delivery would be premature.

After a time-boxed technical investigation, you apply a disposition to handle throwaway code. The DISCARD disposition records learnings via memo to prevent rot, while the PROMOTE disposition triggers a follow-up production-shaped feature ticket.

Yes, you can use GitHub issues to track time-boxed hypothesis testing by formatting the ticket from resolved templates and labeling it as a spike. This enforces engineering governance by requiring explicit budget limits and kill criteria within your SDLC workflow.

The best way to structure a technical exploration and avoid scope creep is to enforce explicit time and effort caps alongside specific kill criteria. This ensures the investigation stops early if conditions are met, providing clear PROMOTE or DISCARD outcomes.