4 min read • Guide 450 of 877
How to Manage Technical Spikes vs Regular Development Tasks?
How to manage technical spikes vs regular development tasks?
Manage spikes differently from regular tasks: spikes are time-boxed research with documented findings as output, while regular tasks produce working code. Use distinct labels (spike vs feature), different definitions of done (document vs deploy), and separate velocity tracking. Spikes inform future tasks.
Spike vs task comparison
| Aspect | Spike | Regular Task |
|---|---|---|
| Purpose | Answer questions | Deliver functionality |
| Output | Documentation | Working code |
| Duration | Time-boxed (1-5 days) | Estimated effort |
| Success | Questions answered | Acceptance criteria met |
| Velocity | May track separately | Counted in velocity |
| Outcome | Informs future tasks | Shippable increment |
Spike labels
| Label | Purpose |
|---|---|
| spike | Research/investigation task |
| spike:1-day | 1 day time-box |
| spike:3-day | 3 day time-box |
| spike:poc | Proof of concept |
| spike:evaluation | Technology evaluation |
| task | Regular implementation |
| feature | Feature development |
| bug | Bug fix |
Spike task template
## Spike: [Question to Answer]
### Type
- [ ] Proof of concept
- [x] Technology evaluation
- [ ] Architecture investigation
- [ ] Feasibility study
### Time-box
Maximum: 3 days
Start: 2025-01-27
End: 2025-01-29
### Questions to Answer
1. Can technology X handle our scale?
2. What's the learning curve?
3. How does it integrate with our stack?
### Approach
[How you'll investigate]
### Definition of Done
- [ ] All questions answered (or determined unanswerable)
- [ ] Findings documented
- [ ] Recommendation made
- [ ] Follow-up tasks created if applicable
### Output
[To be filled with findings]
Regular task template
## Feature: [Feature Name]
### Acceptance Criteria
- [ ] User can perform action A
- [ ] System responds with result B
- [ ] Error cases handled
### Technical Approach
[How to implement - known from prior spike or experience]
### Estimate
3 story points
### Definition of Done
- [ ] Code implemented
- [ ] Tests written
- [ ] Code reviewed
- [ ] Documentation updated
- [ ] Deployed to staging
When to use spike vs task
| Situation | Use |
|---|---|
| "Can we do X?" | Spike |
| "We need to do X" | Task |
| "Which technology?" | Spike |
| "Build with technology X" | Task |
| "How long will Y take?" | Spike |
| "Build Y in N days" | Task |
| "Is Z feasible?" | Spike |
| "Implement Z" | Task |
Spike workflow:
- Identify uncertainty - What don't we know?
- Create spike - Define questions
- Set time-box - Hard deadline
- Investigate - Research, prototype
- Document findings - Answer questions
- Make recommendation - Based on findings
- Create follow-up tasks - Implementation work
- Close spike - At time-box end
Converting spike to tasks
## Spike Findings: GraphQL Evaluation
### Recommendation
Adopt GraphQL for new API endpoints.
### Follow-up Tasks to Create
1. [ ] Set up GraphQL server infrastructure
2. [ ] Create user query schema
3. [ ] Implement user resolvers
4. [ ] Add authentication middleware
5. [ ] Create developer documentation
### Estimate Range
- GraphQL adoption: 3-4 sprints
- Learning curve: 1-2 sprints
- Full migration: 6-8 sprints (optional)