Estimation Guidelines¶

Goal: Estimate relative complexity, not absolute time

Why Estimate?¶

Benefits: - Plan sprint capacity realistically - Identify scope creep early - Track velocity over time - Surface unknowns and risks - Improve over time (calibration)

Not for: - Exact time predictions (humans are bad at this) - Performance reviews (creates perverse incentives) - Commitments to external stakeholders (use buffer)

Estimation Methods¶

Method 1: Story Points (Fibonacci)¶

Scale: 0, 1, 2, 3, 5, 8, 13, 21

Philosophy: Relative sizing, gaps represent uncertainty

0 - Trivial
    - Typo fix
    - Config value change
    - Update comment
    Time: Minutes

1 - Very Small
    - Simple function
    - Clear implementation
    - No unknowns
    Time: < 1 hour

2 - Small
    - Well-defined feature
    - Some testing needed
    - Few edge cases
    Time: 2-4 hours

3 - Medium
    - Clear scope
    - Multiple files
    - Test coverage
    Time: Half day to full day

5 - Large
    - Moderate complexity
    - Some unknowns
    - Integration testing
    Time: 1-2 days

8 - Very Large
    - Complex feature
    - Multiple subsystems
    - Significant testing
    Time: 2-4 days

13 - Huge
    - Very complex
    - Cross-team coordination
    - Should probably break down
    Time: 4-5 days

21 - Epic
    - Too big to estimate accurately
    - MUST break down into smaller pieces
    Time: Week+

Rule: Anything > 8 should be broken down

Method 2: T-Shirt Sizing¶

Scale: XS, S, M, L, XL, XXL

When: Quick estimation, early planning

XS - Extra Small     (< 1 hour)
S  - Small           (half day)
M  - Medium          (1 day)
L  - Large           (2-3 days)
XL - Extra Large     (4-5 days)
XXL - Extra Extra Large (week+, break down)

Conversion to points: - XS = 1 - S = 2 - M = 3 - L = 5 - XL = 8 - XXL = 13+

Method 3: Ideal Days¶

Scale: 0.5, 1, 2, 3, 5

When: Team prefers time-based thinking

0.5 - Half day of focused work
1   - One day of focused work
2   - Two days
3   - Three days
5   - Week (should break down)

Note: "Ideal days" = uninterrupted, no meetings, no context switching

Problem: People confuse with calendar days, creates pressure

Recommendation: Use story points instead

Estimation Process¶

Read issue description
Understand requirements
Review acceptance criteria
Check for linked docs
Ask questions
Clarify scope
Identify edge cases
Surface assumptions
Discuss complexity
Technical challenges
Unknown unknowns
Dependencies
Vote (Planning Poker)
Everyone estimates privately
Reveal simultaneously
Discuss discrepancies
Converge on estimate
Document assumptions
What's included
What's explicitly excluded
Known risks

Planning Poker Example¶

Issue: Add VST3 parameter automation

Round 1 votes: 3, 5, 5, 8

Discussion: - Alice (3): "We already have the infrastructure, just wiring" - Bob (8): "But we need to handle sample-accurate automation" - Carol (5): "Right, plus testing on multiple DAWs"

Round 2 votes: 5, 5, 5, 5

Consensus: 5 points

Document: - Includes: VST3 automation API, sample-accurate timing, basic testing - Excludes: Advanced modulation (separate feature) - Risk: DAW-specific quirks might take extra time

Calibration¶

Baseline Stories¶

Create reference stories for your team:

1-point story:

Example: Fix typo in error message
Actual: Took 15 minutes

3-point story:

Example: Add new parameter to existing processor
Includes: Core logic, tests, documentation
Actual: Took 4 hours

5-point story:

Example: Implement simple DSP effect (gain, pan)
Includes: Algorithm, tests, integration
Actual: Took 1.5 days

8-point story:

Example: Add MIDI learn functionality
Includes: UI, state management, persistence, tests
Actual: Took 3 days

Use these: When estimating, compare to baseline

Tracking Accuracy¶

After completing stories, review:

Underestimated (actual > estimate): - What did we miss? - Edge cases we didn't foresee? - Scope creep during implementation?

Overestimated (actual < estimate): - What was easier than expected? - Did we reuse existing code? - Was scope reduced?

Adjust: Not the original estimate, but future estimates

Common Pitfalls¶

❌ Pitfall 1: Anchoring¶

Problem: First person's estimate biases everyone else

Solution: Planning poker (private votes first)

❌ Pitfall 2: Optimism Bias¶

Problem: Assuming best-case scenario

Solution: Ask "What could go wrong?"

❌ Pitfall 3: Scope Creep¶

Problem: Adding features mid-implementation

Solution: Stick to acceptance criteria, create new issues

❌ Pitfall 4: Comparing People¶

Problem: "Alice is faster than Bob"

Solution: Estimate for average team member

❌ Pitfall 5: Pressure to Commit¶

Problem: Estimates become deadlines

Solution: Clarify estimates ≠ promises

❌ Pitfall 6: Over-Precision¶

Problem: Debating 5 vs 8 for 30 minutes

Solution: If unclear, pick larger (accounts for uncertainty)

❌ Pitfall 7: Ignoring Interruptions¶

Problem: Forgetting meetings, code reviews, support

Solution: Use velocity, not estimates, for planning

Velocity & Capacity¶

Measuring Velocity¶

Velocity = Story points completed per sprint

Example:

Sprint 1: 18 points completed
Sprint 2: 22 points completed
Sprint 3: 20 points completed
───────────────────────────────
Average velocity: 20 points/sprint

Use 3-4 sprints to establish baseline

Capacity Planning¶

Available hours (per person, per 2-week sprint):

Total hours:           80 hours
Meetings/email:        -10 hours (12.5%)
Code review:           -8 hours (10%)
Support/bugs:          -8 hours (10%)
Context switching:     -8 hours (10%)
────────────────────────────────
Focused development:   46 hours (57.5%)

Velocity per person: Depends on team, typically 10-15 points

Sprint capacity (3 engineers):

3 engineers × 13 points = 39 points
Apply 80% buffer = ~31 points committed

Why buffer? - Unplanned work (bugs, support) - Estimation errors - Sick days, PTO - Unknowns

Velocity Trends¶

Increasing velocity could mean: - Team is learning (good!) - Estimates are inflating (bad) - Technical debt accumulating (bad)

Decreasing velocity could mean: - Taking on harder problems (okay) - Technical debt slowing down (bad) - Team morale issues (bad)

Stable velocity (ideal): - Predictable planning - Sustainable pace

Special Cases¶

Bugs¶

Approach 1: Estimate like features - Small bug fix: 1-2 points - Complex bug: 3-5 points - Architecture change: 8+ points

Approach 2: Reserve capacity - Allocate 20% of sprint to bugs - Don't estimate individual bugs

Recommendation: Approach 2 (simpler, accounts for unpredictability)

Spikes (Research)¶

Time-box, don't estimate by complexity: - Half-day spike: 2 points - Full-day spike: 3 points - Two-day spike: 5 points

Deliverable: Document, not code

If spike reveals work: Create new issues, estimate those

Documentation¶

Estimate like code: - Simple README: 1-2 points - API documentation: 3-5 points - Tutorial/guide: 5-8 points

Don't skip: Documentation is real work

Refactoring¶

If standalone: Estimate normally

If part of feature: Include in feature estimate

Large refactor: Break down, make incremental

Audio-Specific Considerations¶

DSP Algorithm Implementation¶

Factors affecting estimate: - Algorithm complexity (simple gain vs convolution) - Platform-specific optimizations (SIMD) - Testing requirements (listening tests, benchmarks) - Reference implementation available?

Example estimates:

Simple effect (gain, pan):        3-5 points
Filter (biquad):                   5-8 points
FFT-based (EQ, analyzer):          8-13 points
Convolution reverb:                13-21 points (break down)
Physical modeling synth:           21+ points (epic)

Performance Optimization¶

Very unpredictable, consider spike first: - Spike: Profile, identify bottleneck (2-3 points) - Then: Estimate optimization based on findings

If blind optimization: Use large estimate (8+)

Platform-Specific Work¶

Multiplication factor: - Single platform (Windows): 1x - Two platforms (Win + Mac): 1.5x (not 2x, sharing code) - Three platforms (Win + Mac + Linux): 2x

Testing overhead: Each platform needs testing

DAW Compatibility Testing¶

Per DAW: ~1-2 points additional - Test basic functionality - Quirks and workarounds - Automation testing

Budget: If supporting 5 DAWs, add 5-10 points to feature

Team Agreement¶

Document your team's estimation standards:

# AudioLab Estimation Agreement

## Scale
We use Fibonacci story points: 0, 1, 2, 3, 5, 8, 13, 21

## Reference Stories
- 1pt: Simple parameter addition
- 3pt: Basic DSP effect
- 5pt: Complex feature with tests
- 8pt: Cross-platform feature

## Process
- Estimate during backlog refinement
- Use planning poker
- Break down anything > 8 points

## Velocity
- Target: 13 points/person/sprint
- Track: Rolling 4-sprint average
- Buffer: 20% for bugs and unknowns

## Re-estimation
- If scope changes significantly
- If during implementation we discover estimate was off > 2x
- Document in issue why estimate changed

Review: Quarterly, adjust based on learnings

Tools¶

Planning Poker Apps¶

Planning Poker Online: Free, web-based
Scrum Poker Cards: Physical cards
Slack/Discord bots: In-chat voting

Velocity Tracking¶

Linear: Built-in velocity charts
GitHub Projects: Manual (export CSV, spreadsheet)
Spreadsheet: Simple, flexible

Examples¶

Example 1: Feature Estimation¶

Issue: Add stereo width control to processor

Discussion: - Algorithm: Simple M/S processing (easy) - UI: Slider + visualization (moderate) - Testing: Listening tests across DAWs (time-consuming) - Documentation: Update manual (included)

Estimate: 5 points

Breakdown: - Core algorithm: 1 point - UI integration: 2 points - Testing + docs: 2 points

Example 2: Bug Estimation¶

Issue: Crash when loading preset with NaN values

Discussion: - Reproduce: Easy (steps provided) - Fix: Add validation (straightforward) - Testing: Verify fix, add unit test (standard) - Edge cases: Check all parameters (some work)

Estimate: 3 points

Example 3: Spike Estimation¶

Issue: Investigate switching from FFT to wavelet transform

Discussion: - Time-box: 1 day of research - Deliverable: Document with recommendation - No code expected (proof-of-concept optional)

Estimate: 3 points (1-day spike)

Follow-up: Create implementation issues based on findings

Resources¶

Remember: Estimates are guesses, not commitments. The goal is to plan, not to be perfect.