Test-Driven Development (TDD) and Scrum: A Practical How-To Guide
Scrum is a framework for managing product development work. It prescribes roles, events, and artefacts, but it deliberately says nothing about engineering practices. How the Development Team builds the Increment — the practices, tools, and disciplines they apply — is outside Scrum's scope. This is intentional: Scrum is meant to work across contexts, and engineering practices that are appropriate for one technology stack may not translate to another. But this silence also means that Scrum teams must make their own choices about engineering practices, and those choices have significant consequences for the team's ability to meet Scrum's core requirement: producing a potentially releasable Increment at the end of every Sprint. Test-Driven Development is one of the practices best suited to supporting that requirement.
What TDD is: the red-green-refactor cycle
Test-Driven Development is a discipline in which the developer writes an automated test before writing the code the test is meant to validate. The cycle has three steps, repeated continuously: write a test that specifies a desired behaviour and watch it fail (red); write the minimum code necessary to make the test pass (green); refactor the code to improve its design without changing its behaviour (refactor). This cycle — red, green, refactor — is the fundamental unit of TDD practice. A developer working with TDD may go through this cycle dozens of times in a day, with each cycle adding a small increment of working, tested behaviour. The test suite that accumulates over time becomes a safety net: any regression introduced by later changes will cause one of the existing tests to fail, catching the problem immediately rather than at integration or release.
How TDD fits Scrum
Scrum's Definition of Done is the team's shared understanding of what it means for work to be complete. In most professional contexts, the Definition of Done includes testing requirements — unit tests passed, integration tests passed, code reviewed, and so on. TDD supports the Definition of Done in a specific and powerful way: it makes testing inseparable from development rather than a separate step that follows it. A developer who writes the test first cannot complete a unit of work without also completing the test for it. There is no "build now, test later" option in TDD — the test is the first thing written. This matters for Scrum because the Sprint commitment is to deliver a truly done Increment, not a partially done body of work with testing deferred to the next Sprint. Teams that separate development from testing accumulate testing debt that makes it progressively harder to deliver a genuinely done Increment in each Sprint.
TDD in the sprint: where it fits
In a Scrum Sprint, TDD is applied at the task level within Sprint backlog items. During Sprint Planning, the team breaks Product Backlog Items into tasks. For each development task, the developer applies the red-green-refactor cycle as the unit of work. Daily Scrum updates can reference test passage rates as an objective indicator of progress — "all unit tests passing, working on the integration scenario" is more informative than "it's about sixty percent done." Sprint Review demonstrations benefit from showing the automated test suite: it makes the quality of the Increment visible to stakeholders, not just the functionality. The Sprint Retrospective is a natural point to review TDD discipline — whether tests are being written first, whether the test suite coverage is growing, and whether regressions are being caught early or late.
Common objections and how to address them
"TDD takes too long." This is the most common objection and it is usually based on comparing TDD to writing code without tests at all. The correct comparison is TDD versus writing code and then testing it. TDD does not eliminate testing — it changes when testing happens and who does it. The time cost of writing tests is real in the short term and offset in the medium term by reduced debugging time and reduced regression cycles. Teams that have used TDD consistently for more than a few sprints rarely report wanting to go back.
"It's hard to retrofit." True. TDD is significantly easier to apply to new code than to add tests to legacy code. Legacy code was not designed with testability in mind, which means the coupling and dependency structures that TDD naturally avoids are already baked in. The pragmatic approach is to apply TDD to new code and to any legacy code that must be modified, using the modification as an opportunity to improve testability before making the change.
"Our team has never done it before." The best way to introduce TDD to a team is through facilitated practice — a coding kata or mob programming session where the whole team works through the red-green-refactor cycle together, ideally guided by someone with TDD experience. One session rarely makes TDD stick. It needs to be practised repeatedly, and the team needs to make it explicit in the Definition of Done so there is an accountable commitment rather than an optional aspiration.
If your Scrum team is struggling to consistently deliver a truly done Increment each Sprint — whether due to testing debt, regressions, or unclear Definition of Done — XNM's program and project delivery advisory can help diagnose the underlying delivery model issues and design a path to sustainable, high-quality Sprint delivery.