PSD study materials
PSD study resources

PSD: Development Practices and Techniques That Support Building Software with Scrum

PSD · Work through your exam, one topic at a time.

All guide sections

Development Practices and Techniques That Support Building Software with Scrum

What this domain tests

This domain tests the engineering discipline that makes a Done Increment possible each Sprint. Scrum does not mandate specific practices, but it does mandate a Definition of Done that yields a releasable Increment - which in software almost always requires automation, integration, and design discipline.

Practices that support Done

  • Test-first and automated testing at unit, integration, and acceptance levels; a balanced test pyramid rather than an ice-cream cone of manual regression.
  • Continuous Integration: integrate to a shared trunk at least daily, run an automated build and test suite, and fix a broken build before starting new work.
  • Refactoring and emergent design: keep the design as simple as it needs to be now, and improve structure continuously instead of relying on a big design up front.
  • Collective code ownership and peer review, including pair programming, so knowledge does not sit with one person.
  • Deployment automation: infrastructure as code, pipelines, feature flags, and observability, so releasing is routine rather than an event.

Worked example

A team runs three-week Sprints but needs two weeks of manual regression before anything can ship. Their Definition of Done therefore says "code complete and demoed", and their Increment is never releasable. The reasoning: the constraint is the batch of untested change, not the Sprint length. The team attacks it by automating the highest-risk regression tests first, adding CI, and slicing backlog items smaller so each is testable within the Sprint. The Definition of Done is then expanded as capability grows. Creating a separate QA phase or a "testing Sprint" just relocates the problem and hides it from inspection.

Traps that cost marks

Assuming Scrum prescribes TDD or XP practices - it prescribes the outcome, the team chooses the practice; equating Done with "deployed to production" (the Increment must be releasable, not released); tracking technical debt somewhere outside the Product Backlog; and adding a hardening phase instead of raising the Definition of Done.