Estimation Without User Stories

Estimation Without User Stories

Not everything in a backlog is a "As a user, I want..." story. Infrastructure tasks, DevOps work, refactoring, and platform migrations need estimation too.

The Challenge

User stories have built-in structure: role, action, and value. Technical tasks often lack this clarity, which makes estimation harder:

• "Upgrade Kubernetes to 1.29" -- How complex is this? It depends on cluster size, custom resources, deprecated APIs...
• "Set up CI/CD for the new service" -- What is the baseline? Docker? Helm? ArgoCD?
• "Reduce API latency by 50ms" -- Investigation alone could take days.

Estimation Strategies for Technical Work

1. Decompose into checkboxes

Break the task into concrete steps, then estimate the aggregate.

"Upgrade PostgreSQL from 14 to 16"
  □ Review breaking changes in release notes (spike, 2 hrs)
  □ Update connection string configuration (1 pt)
  □ Run migration on staging (2 pts)
  □ Performance test on staging (2 pts)
  □ Schedule maintenance window (0 pts)
  □ Execute production migration (2 pts)
  □ Verify and monitor (1 pt)
  → Total: 8 points

2. Estimate by risk, not by code

For DevOps work, the risk of something going wrong matters more than the amount of code changed.

Changing a DNS record:
  Lines of code: 1
  Risk: HIGH (wrong value = total outage)
  Rollback complexity: Medium (DNS propagation delay)
  → 5 points (mostly risk-driven)

3. Use time-based reference for infrastructure

When the team has no relative benchmark, anchor to actual hours for the first few items, then switch to relative estimation.

Reference: "Deploy a new microservice with standard template" = 3 pts (~1 day)
New item: "Set up monitoring dashboards for 5 services" = 5 pts (more complex, multiple services)

4. Spike aggressively

Technical work has more unknowns than typical user stories. Use spikes liberally:

• Spike to understand the problem (time-boxed)
• Estimate only after the spike reduces uncertainty
• Execute with confidence

Template for Technical Tasks

When writing technical items, include:

• What changes (specific systems, files, configurations)
• Why it matters (performance, security, reliability)
• Acceptance criteria (measurable outcomes)
• Rollback plan (how to undo if something goes wrong)

This gives the team enough context to estimate confidently, even without the user story format.