TDD and Estimation: How Tests Affect Sprint Planning
A team that practices TDD estimates differently from a team that does not — and the numbers are significantly higher. Not because TDD is slower, but because it exposes complexity that coding without tests tends to hide.
The True Cost of a Feature
When someone asks “how much to implement OAuth login?”, the naive answer considers:
- Create the login form
- Integrate with OAuth provider
- Save the session
The realistic answer (with TDD) considers:
- Tests for the form (inputs, validation, loading states)
- Tests for the integration (success, error, timeout)
- Tests for sessions (creation, expiration, refresh)
- Mocking the provider for test environments
- Edge cases (existing user, missing data)
The result: what looked like 5 points becomes 8.
Does TDD Increase or Decrease Estimates?
Short term: It increases
Writing tests before production code takes more time upfront. Estimates reflect that.
Long term: It decreases
- Fewer bugs means less unplanned rework
- Safe refactoring means changes do not introduce regressions
- Living documentation means tests describe expected behavior
- Faster onboarding means new members understand the code through its tests
Include Tests in the Definition of Done
If your DoD includes tests (and it should), estimates must include the testing effort:
“This CRUD feature needs: unit tests for the service, integration tests for the controller, E2E tests for the flow. All of that is included in the 8 points.”
The Testless Team Paradox
Teams that do not write tests estimate lower because:
- They do not count testing time (which they will still need)
- They do not account for debugging the bugs that inevitably appear
The result is false efficiency: “we did it in 3 days” (but spent 2 days fixing the resulting bugs).
Estimating Tests Separately
Some teams split feature estimation and test estimation:
| Item | Feature Points | Test Points | Total |
|---|---|---|---|
| OAuth Login | 5 | 3 | 8 |
| Profile Page | 3 | 2 | 5 |
| PDF Export | 5 | 5 | 10 |
This makes testability cost visible. If test points are consistently high, it may indicate code that is hard to test — a technical debt signal.
Benchmarks by Test Type
A practical rule of thumb for effort distribution:
- Unit tests: 30-40% of total effort
- Integration tests: 20-30% of total effort
- E2E tests: 20-30% of total effort
- Manual/exploratory tests: 10-20% of total effort
TDD and Planning Poker
When running Planning Poker with TDD:
- Vote for the total effort (feature + tests)
- If someone votes higher, they may be thinking about tests others forgot
- “That is 5 points without tests, but 8 with full test coverage” is a perfectly valid discussion
Conclusion
Teams using TDD estimate higher but deliver more predictably because their estimates include the full scope of real work. If your team does not include testing in estimates, you are systematically underestimating — and the bill comes due in bugs and rework.