9 min read • Guide 815 of 877
Technical Discovery Spikes
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 │
└─────────────────────────────────────────────────────────────┘