6.5 Development Practices That Protect the Increment
Key Takeaways
- CSM LO 3.3 asks you to list at least three development practices that help a Scrum Team deliver a high-quality Increment and reduce technical debt each Sprint.
- Scrum deliberately prescribes no engineering practices — it is 'purposefully incomplete' — but a team that adopts none cannot produce a Done Increment every Sprint.
- The highest-leverage practices are automated testing, continuous integration, refactoring, pair or ensemble programming, and peer code review.
- Practices become durable when they are written into the Definition of Done; otherwise they are the first thing dropped under deadline pressure.
- The Scrum Master does not mandate engineering practices; they make the cost of their absence visible and coach the Developers toward their own choices.
Quick Answer: Scrum prescribes no engineering practices, but requires a usable Increment every Sprint — which is impossible without them. The practices to name: automated testing (unit, integration, regression), continuous integration, refactoring, pair or ensemble programming, peer code review, test-driven development, and automated deployment. Any three satisfy CSM Learning Objective 3.3.
The Scrum Guide is explicit that "the Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory," and that "various processes, techniques and methods can be employed within the framework." That is not an invitation to skip technical discipline — it is a statement that Scrum leaves the choice to the people doing the work, while the Definition of Done and the Increment set a bar those choices must clear.
Why This Sits in a Scrum Master Chapter
Two Scrum Master accountabilities lead directly here: helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done, and causing the removal of impediments. When a team cannot finish anything in a Sprint because every change breaks something else, that is an impediment with a technical root — and the Scrum Master who treats it as purely a technical matter for others is not serving the team.
The Practices and What Each One Prevents
| Practice | What It Is | Debt It Prevents | Effect on the Increment |
|---|---|---|---|
| Automated testing | Unit, integration, and regression tests run without human effort | Fear of change; manual test cycles that cannot fit in a Sprint | Regression risk is bounded, so the Increment stays usable as it grows |
| Continuous integration | Every change is merged and verified against the mainline frequently | Long-lived branches and painful merge conflicts | Integration is continuous, so no integration phase is needed |
| Refactoring | Improving internal structure without changing behaviour | Structural decay that makes each change costlier than the last | Sustains the team's ability to deliver at a steady pace |
| Test-driven development | Writing the failing test before the implementation | Untested paths and speculative design | Design is shaped by verifiable behaviour |
| Pair / ensemble programming | Two or more Developers working on the same problem together | Knowledge silos; single points of failure; late-arriving review feedback | Cross-functionality genuinely increases; review is continuous |
| Peer code review | Another Developer reviews before merge | Undetected defects; divergent standards | A shared quality bar the whole team upholds |
| Automated deployment | Repeatable, scripted release to environments | Manual release rituals that only one person can perform | Increments can be delivered whenever the Product Owner chooses |
| Trunk-based development | Short-lived branches merged frequently | Divergence between what is built and what is integrated | The mainline stays releasable |
If asked for three, the strongest trio is automated testing, continuous integration, and refactoring — they attack the three distinct causes of a team's inability to finish: regression risk, integration cost, and structural decay.
Practices Only Stick When They Are in the Definition of Done
A team can agree in a Retrospective to review all code, and quietly abandon it three Sprints later when a deadline arrives. Writing the practice into the Definition of Done changes its status: a Product Backlog item that has not been peer-reviewed is not Done, cannot be part of the Increment, and cannot be presented at the Sprint Review.
This is the practical link between the technical topic and the artifact topic. Quality practices that live in a team agreement are aspirations; quality practices that live in the Definition of Done are constraints — and the Scrum Guide is explicit that "the Developers are required to conform to the Definition of Done."
The Debt Spiral, and Where to Break It
Unaddressed technical debt produces a self-reinforcing loop that CSM scenarios describe frequently:
- Deadline pressure leads to expedient shortcuts.
- The codebase becomes harder to change, so each subsequent item costs more.
- Less gets finished per Sprint, so pressure increases.
- More shortcuts are taken. Return to step 2.
The loop cannot be broken by working harder, and it cannot be broken by a hardening Sprint — quality does not decrease during the Sprint, and a separate remediation Sprint produces no valuable Increment while implicitly licensing the shortcuts that made it necessary. It is broken by making the debt visible on the Product Backlog, where the Product Owner can order it against feature work, and by strengthening the Definition of Done so new debt stops accruing at the same rate.
How the Scrum Master Influences Technical Practice
The Scrum Master has no technical authority and cannot mandate a practice. What they can do:
- Make the cost visible. Convert recurring pain into figures the team and Product Owner can weigh — hours lost to manual regression testing, Sprints in which the Sprint Goal was missed due to a broken build, defect escape rates.
- Create the space. Ensure the Product Owner understands why capacity spent on refactoring or test automation protects future delivery, so it competes fairly rather than being done in secret.
- Bring in expertise. The Scrum Master is not required to be the technical coach. Arranging one, or connecting the team with a stronger team internally, is a legitimate way to cause the removal of the impediment.
- Route it through the Retrospective. Practice adoption is a process adaptation and belongs where the team owns the decision.
- Protect the standard when it is challenged. When an executive asks to ship something that does not meet the Definition of Done, the Scrum Master's job is to hold the line and explain the cost.
Real-World CSM Scenario
A team cannot complete anything in the last three days of each Sprint because a two-day manual regression test must run first, and any defect it finds restarts the cycle.
The Scrum Master does not prescribe a testing framework. They quantify: 30% of every Sprint spent on manual regression, and three of the last five Sprint Goals missed as a result. That figure changes the conversation, because the Product Owner can now see that automating the top twenty regression cases buys back capacity permanently rather than costing it.
The team places the automation work on the Product Backlog, where the Product Owner orders it explicitly, and adds "automated regression suite passes" to the Definition of Done once the suite actually exists — in that order. Adding the criterion first would have created a bar the team could not clear, which is how Definitions of Done become fiction.
Which set of practices most directly helps a Scrum Team deliver a high-quality Increment and reduce technical debt each Sprint?
Why does the Scrum Guide prescribe no specific engineering practices?
A team agrees in a Retrospective to peer-review all code, but abandons the practice three Sprints later under deadline pressure. What would have made the practice durable?
A Scrum Team's codebase has degraded to the point that each new feature takes longer than the last. Which response is consistent with Scrum?