8 min read • Guide 793 of 877
Technical Spikes and Research Tasks
Spikes answer questions before you invest in solutions. GitScrum helps teams track research work and capture learnings for future reference.
When to Spike
Identifying Need
WHEN TO DO A SPIKE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DO A SPIKE WHEN: │
│ ──────────────── │
│ │
│ FEASIBILITY UNKNOWN: │
│ "Can we even do this?" │
│ "Will this technology work for our use case?" │
│ "Is this technically possible?" │
│ │
│ ESTIMATE UNCERTAIN: │
│ "We have no idea how long this will take" │
│ "Team has never done this before" │
│ "Could be 2 days or 2 weeks" │
│ │
│ MULTIPLE OPTIONS: │
│ "Should we use Library A or Library B?" │
│ "What's the best approach?" │
│ "We need to compare options" │
│ │
│ INTEGRATION RISK: │
│ "Will this work with our existing system?" │
│ "How do we connect to this API?" │
│ "What's the performance impact?" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DON'T SPIKE WHEN: │
│ ───────────────── │
│ ❌ Team already knows the answer │
│ ❌ It's a familiar type of work │
│ ❌ Spike would take as long as just doing it │
│ ❌ Analysis paralysis - just try it │
└─────────────────────────────────────────────────────────────┘
Spike Structure
Creating Effective Spikes
SPIKE TEMPLATE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SPIKE: PDF Generation Approach │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TYPE: Technical Spike ││
│ │ TIME BOX: 2 days ││
│ │ OWNER: @alex ││
│ │ ││
│ │ QUESTION TO ANSWER: ││
│ │ Which PDF library should we use for invoice ││
│ │ generation that supports our requirements? ││
│ │ ││
│ │ CONTEXT: ││
│ │ • Need to generate invoices with tables, logos ││
│ │ • Must support multiple languages (RTL included) ││
│ │ • Target: < 2 seconds per document ││
│ │ • Volume: ~1000 documents/day ││
│ │ ││
│ │ SUCCESS CRITERIA: ││
│ │ ☐ Recommendation with rationale ││
│ │ ☐ Proof of concept with sample invoice ││
│ │ ☐ Performance benchmarks ││
│ │ ☐ Estimate for full implementation ││
│ │ ││
│ │ OPTIONS TO EXPLORE: ││
│ │ 1. PDFKit (client-side) ││
│ │ 2. Puppeteer (headless Chrome) ││
│ │ 3. WeasyPrint (Python) ││
│ │ 4. wkhtmltopdf ││
│ │ ││
│ │ OUTPUT: ││
│ │ Document with findings linked to this task ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ KEY ELEMENTS: │
│ • Clear question (not vague exploration) │
│ • Time box (prevents rabbit holes) │
│ • Success criteria (know when done) │
│ • Expected output (document, prototype, estimate) │
└─────────────────────────────────────────────────────────────┘
Types of Spikes
SPIKE CATEGORIES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TECHNICAL SPIKE: │
│ ──────────────── │
│ Explore technical approach or feasibility │
│ │
│ Examples: │
│ • "Can we use GraphQL with our current stack?" │
│ • "How do we integrate with Salesforce API?" │
│ • "What's the best caching strategy?" │
│ │
│ Output: Technical document, prototype, recommendation │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ FUNCTIONAL SPIKE: │
│ ───────────────── │
│ Explore user needs or requirements │
│ │
│ Examples: │
│ • "What do users actually need from this feature?" │
│ • "How do competitors solve this?" │
│ • "What are the edge cases?" │
│ │
│ Output: User research, requirements document, mockups │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ESTIMATION SPIKE: │
│ ───────────────── │
│ Reduce uncertainty to enable estimation │
│ │
│ Examples: │
│ • "How much work is the migration?" │
│ • "What's involved in upgrading to v3?" │
│ • "How complex is this integration?" │
│ │
│ Output: Rough estimates, risk assessment, task breakdown │
└─────────────────────────────────────────────────────────────┘
Running Spikes
Time-Boxing
TIME BOX DISCIPLINE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ WHY TIME BOX: │
│ ───────────── │
│ • Prevents analysis paralysis │
│ • Forces decisions with available info │
│ • Limits investment in exploration │
│ • Keeps sprint predictable │
│ │
│ TYPICAL TIME BOXES: │
│ • 1 day: Quick investigation │
│ • 2 days: Moderate exploration │
│ • 3-5 days: Complex research (rare) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ WHEN TIME BOX ENDS: │
│ ─────────────────── │
│ │
│ SCENARIO 1: QUESTION ANSWERED │
│ Great! Document findings, close spike │
│ Estimate follow-on story │
│ │
│ SCENARIO 2: NEED MORE TIME │
│ ❌ DON'T: Just keep going │
│ ✅ DO: Report what you learned │
│ ✅ DO: Decide if more time is worth it │
│ ✅ DO: Re-scope if continuing │
│ │
│ SCENARIO 3: ANSWER IS "NO" │
│ This is still valuable! │
│ "We learned this approach won't work" │
│ Document why, explore alternatives │
│ │
│ SPIKE OUTCOME TASK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SPIKE-456: PDF Generation Approach (COMPLETE) ││
│ │ ││
│ │ TIME USED: 1.5 days (of 2 day box) ││
│ │ ││
│ │ FINDINGS: ││
│ │ Recommend Puppeteer for PDF generation ││
│ │ • Best quality ││
│ │ • Meets performance requirements ││
│ │ • Team has JS experience ││
│ │ ││
│ │ POC: Created sample invoice in /spikes/pdf-gen ││
│ │ Perf: 1.2 seconds per document ✅ ││
│ │ ││
│ │ FOLLOW-ON ESTIMATE: ││
│ │ Full implementation: 5 points ││
│ │ ││
│ │ NEXT: Create story STORY-789 for implementation ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Documenting Results
Capturing Learnings
SPIKE DOCUMENTATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SPIKE OUTPUT TEMPLATE: │
│ │
│ # PDF Generation Spike - Findings │
│ │
│ ## Question │
│ Which PDF library should we use for invoice generation? │
│ │
│ ## Options Evaluated │
│ │
│ | Library | Performance | Quality | RTL | Complexity | │
│ |------------|-------------|---------|-----|------------| │
│ | PDFKit | Fast | Medium | ❌ | Low | │
│ | Puppeteer | Medium | High | ✅ | Medium | │
│ | WeasyPrint | Slow | High | ✅ | Low | │
│ | wkhtmltopdf| Medium | Medium | ✅ | Low | │
│ │
│ ## Recommendation │
│ **Puppeteer** - Best balance of quality and performance │
│ │
│ ### Rationale │
│ - Best visual quality (uses Chrome rendering) │
│ - Meets performance SLA (1.2s per doc) │
│ - Team familiar with JavaScript │
│ - Active community and maintenance │
│ │
│ ## Proof of Concept │
│ Location: `/spikes/pdf-generation/` │
│ Sample output: `/spikes/pdf-generation/sample-invoice.pdf`│
│ │
│ ## Risks │
│ - Chrome dependency adds memory overhead │
│ - Need to manage Chrome process lifecycle │
│ │
│ ## Implementation Estimate │
│ - Setup Puppeteer: 1 point │
│ - Invoice template: 2 points │
│ - Testing + edge cases: 2 points │
│ **Total: 5 points** │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ LINK: Attach document to spike task │
│ Future teams can reference this research │
└─────────────────────────────────────────────────────────────┘
Spike in Workflow
Planning for Spikes
SPIKES IN SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BEFORE SPRINT: │
│ ────────────── │
│ In refinement, identify stories with uncertainty │
│ "We can't estimate STORY-456 - need spike first" │
│ │
│ DURING PLANNING: │
│ ──────────────── │
│ Include spike in sprint backlog │
│ Time-box is the "estimate" │
│ Story that depends on spike goes to next sprint │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPRINT BACKLOG: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Sprint 14 Backlog ││
│ │ ││
│ │ STORIES: ││
│ │ • STORY-789: User login (5 pts) ││
│ │ • STORY-790: Password reset (3 pts) ││
│ │ • STORY-791: Dashboard widgets (8 pts) ││
│ │ ││
│ │ SPIKES: ││
│ │ • SPIKE-456: PDF generation approach (2 days) ││
│ │ • SPIKE-457: SSO integration feasibility (1 day) ││
│ │ ││
│ │ NOTE: PDF story (STORY-792) planned for Sprint 15 ││
│ │ pending spike results ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AFTER SPIKE: │
│ ──────────── │
│ 1. Document findings │
│ 2. Create/refine follow-on story │
│ 3. Estimate based on learnings │
│ 4. Add to backlog for next sprint │
└─────────────────────────────────────────────────────────────┘