Technical Discovery Spikes | Time-Boxed Investigation
Run time-boxed spikes to reduce technical uncertainty before implementation. GitScrum tracks spike tasks with deliverables, estimates, and outcomes.
9 min read
Spikes reduce risk. GitScrum helps teams plan and track technical spikes that answer critical questions before committing to full implementation.
Understanding Spikes
What Are Spikes
SPIKE DEFINITION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SPIKE: │
│ ────── │
│ A time-boxed investigation to answer a question │
│ │
│ PURPOSE: │
│ ──────── │
│ • Reduce technical uncertainty │
│ • Explore unfamiliar technology │
│ • Assess feasibility │
│ • Inform estimation │
│ • Prototype approaches │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE vs STORY: │
│ │
│ STORY: │
│ "Implement user authentication with OAuth" │
│ OUTPUT: Working feature in production │
│ │
│ SPIKE: │
│ "Investigate OAuth providers for our requirements" │
│ OUTPUT: Recommendation + approach + estimate │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ WHEN TO SPIKE: │
│ ────────────── │
│ │
│ ✅ Use spike when: │
│ • "Can we even do this?" │
│ • "Which approach is better?" │
│ • "How long will this take?" │
│ • "What are the risks?" │
│ │
│ ❌ Don't spike when: │
│ • Answer is Googleable in 30 minutes │
│ • You already know the approach │
│ • Just start building │
│ │
│ RULE: Spike when uncertainty is blocking progress │
└─────────────────────────────────────────────────────────────┘
Types of Spikes
Spike Categories
SPIKE TYPES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FEASIBILITY SPIKE: │
│ ────────────────── │
│ "Can we do this?" │
│ │
│ EXAMPLE: │
│ "Can we integrate with their legacy API?" │
│ • Test API connectivity │
│ • Identify limitations │
│ • Document blockers │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ARCHITECTURE SPIKE: │
│ ─────────────────── │
│ "How should we structure this?" │
│ │
│ EXAMPLE: │
│ "Design the microservices architecture" │
│ • Service boundaries │
│ • Communication patterns │
│ • Data flow │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TECHNOLOGY SPIKE: │
│ ───────────────── │
│ "Which technology should we use?" │
│ │
│ EXAMPLE: │
│ "Evaluate GraphQL vs REST for our mobile API" │
│ • Compare options │
│ • Prototype both │
│ • Recommend with reasoning │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ESTIMATION SPIKE: │
│ ──────────────── │
│ "How long will this take?" │
│ │
│ EXAMPLE: │
│ "Estimate effort for payment system migration" │
│ • Break down into components │
│ • Identify unknowns │
│ • Provide range estimate │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PROOF OF CONCEPT (POC): │
│ ──────────────────────── │
│ "Does this approach work?" │
│ │
│ EXAMPLE: │
│ "Prototype real-time sync mechanism" │
│ • Build minimal working version │
│ • Validate core assumptions │
│ • NOT production code │
└─────────────────────────────────────────────────────────────┘
Planning Spikes
Spike Structure
SPIKE TICKET TEMPLATE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TITLE: [SPIKE] Evaluate message queue options │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ QUESTION TO ANSWER: │
│ ─────────────────── │
│ Which message queue (Kafka, RabbitMQ, SQS) best fits │
│ our async processing needs? │
│ │
│ CONTEXT: │
│ ──────── │
│ We need reliable async processing for: │
│ • Order processing (1K/day) │
│ • Email notifications │
│ • Webhook deliveries │
│ │
│ Current constraints: │
│ • AWS infrastructure │
│ • Small ops team │
│ • Budget: $500/month max │
│ │
│ TIME BOX: 2 days │
│ ──────── │
│ │
│ DELIVERABLES: │
│ ──────────── │
│ ☐ Comparison matrix (features, cost, complexity) │
│ ☐ POC with top 2 options │
│ ☐ Recommendation with reasoning │
│ ☐ Implementation estimate │
│ │
│ ASSIGNED: @alex │
│ DUE: End of day Thursday │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE OUTPUT CHECKLIST: │
│ ☐ Question answered │
│ ☐ Assumptions documented │
│ ☐ Risks identified │
│ ☐ Next steps clear │
│ ☐ Knowledge shared with team │
└─────────────────────────────────────────────────────────────┘
Executing Spikes
Spike Workflow
SPIKE EXECUTION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DAY 1: EXPLORE │
│ ────────────── │
│ │
│ MORNING: │
│ • Review existing knowledge │
│ • Research options │
│ • List assumptions │
│ │
│ AFTERNOON: │
│ • Start prototyping │
│ • Test basic scenarios │
│ • Document findings as you go │
│ │
│ END OF DAY: │
│ • Checkpoint: On track? Need more time? │
│ • Note blocking questions │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DAY 2: CONCLUDE │
│ ─────────────── │
│ │
│ MORNING: │
│ • Complete investigation │
│ • Answer remaining questions │
│ • Finalize recommendation │
│ │
│ AFTERNOON: │
│ • Write up findings │
│ • Prepare presentation │
│ • Share with team │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ BEST PRACTICES: │
│ ─────────────── │
│ │
│ TIME-BOX STRICTLY: │
│ • Stop when time is up │
│ • "We don't know yet" is valid answer │
│ • Avoid scope creep │
│ │
│ DOCUMENT AS YOU GO: │
│ • Don't wait until the end │
│ • Note dead ends too │
│ • Future you will thank you │
│ │
│ SHARE EARLY: │
│ • Quick team sync mid-spike │
│ • Get input on direction │
│ • Avoid going down wrong path │
│ │
│ POC CODE IS THROWAWAY: │
│ • Don't gold-plate │
│ • Prove it works, that's all │
│ • Real implementation will be different │
└─────────────────────────────────────────────────────────────┘
Spike Output
Documentation
SPIKE REPORT TEMPLATE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SPIKE REPORT: Message Queue Evaluation │
│ ═══════════════════════════════════════ │
│ │
│ AUTHOR: @alex │
│ DATE: January 15, 2025 │
│ TIME SPENT: 2 days │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SUMMARY: │
│ ──────── │
│ Recommend Amazon SQS for our async processing needs. │
│ It meets our requirements with lowest operational burden. │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ OPTIONS EVALUATED: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Kafka RabbitMQ SQS ││
│ │ ─────────────────────────────────────────────────────── ││
│ │ Throughput High Medium Medium ││
│ │ Complexity High Medium Low ││
│ │ Cost/month $200+ $150+ $20 ││
│ │ Ops burden High Medium Minimal ││
│ │ AWS native No No Yes ││
│ │ Ordering Yes Yes FIFO option ││
│ │ Dead letter Manual Yes Yes ││
│ │ ─────────────────────────────────────────────────────── ││
│ │ FIT: Overkill Possible Best fit ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RECOMMENDATION: │
│ ─────────────── │
│ Amazon SQS with FIFO queues │
│ │
│ REASONS: │
│ 1. Lowest operational burden (managed service) │
│ 2. Cost-effective at our scale ($20/month vs $200) │
│ 3. Native AWS integration │
│ 4. FIFO option for ordering when needed │
│ 5. Built-in dead letter queues │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RISKS & MITIGATIONS: │
│ ──────────────────── │
│ • 256KB message limit → Use S3 for large payloads │
│ • Vendor lock-in → Acceptable given AWS commitment │
│ • Max 14-day retention → Adequate for our use case │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ IMPLEMENTATION ESTIMATE: │
│ ──────────────────────── │
│ • Queue setup: 1 day │
│ • Producer integration: 2 days │
│ • Consumer implementation: 3 days │
│ • Testing & monitoring: 2 days │
│ TOTAL: ~2 sprints │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NEXT STEPS: │
│ • Team review of recommendation │
│ • If approved, create implementation stories │
│ • Schedule architecture review │
│ │
│ ATTACHMENTS: │
│ [POC code] [Cost comparison spreadsheet] │
└─────────────────────────────────────────────────────────────┘
Managing Spikes
Spike Hygiene
SPIKE MANAGEMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRACKING IN GITSCRUM: │
│ ───────────────────── │
│ │
│ • Label: "spike" or "technical-discovery" │
│ • Time estimate: Always include │
│ • Link to related stories │
│ • Track in sprint (counts toward capacity) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE WORKFLOW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TODO │ IN PROGRESS │ IN REVIEW │ DONE ││
│ │ │ │ │ ││
│ │ ┌──────┐│ ┌──────────┐│ │ ┌───────────────┐ ││
│ │ │SPIKE ││ │ SPIKE ││ │ │SPIKE: Auth │ ││
│ │ │OAuth ││ │ MsgQueue││ │ │✓ Complete │ ││
│ │ │2 days││ │ 2 days ││ │ │Report linked │ ││
│ │ └──────┘│ └──────────┘│ │ └───────────────┘ ││
│ │ │ │ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ COMMON MISTAKES: │
│ ──────────────── │
│ │
│ ❌ SPIKE TOO LONG: │
│ "Spike: Evaluate all cloud providers" (2 weeks) │
│ → Too broad, break into smaller spikes │
│ │
│ ❌ SPIKE = STORY: │
│ Starting to build real feature during spike │
│ → Stop, spike is for learning only │
│ │
│ ❌ NO OUTPUT: │
│ "I investigated but didn't write anything down" │
│ → Always document findings │
│ │
│ ❌ ANALYSIS PARALYSIS: │
│ "Need one more day to be sure" │
│ → Time-box is strict, make decision with info you have │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE HEALTH: │
│ ───────────── │
│ • Spikes: 5-15% of sprint capacity │
│ • If higher: Too much uncertainty, break work smaller │
│ • If zero: Might be missing risk reduction │
└─────────────────────────────────────────────────────────────┘