Scrum Sets Quality Expectations. Engineering Practices Make Them Real.

A Sprint can end with every task marked complete and still leave a difficult question unanswered: is the resulting software actually usable, integrated, and safe enough for its intended purpose?

A completed board is useful for tracking work. It is not evidence that a checkout flow handles rejected payments, a new form preserves keyboard access, or one developer’s change still works alongside everyone else’s. Those questions need more than a status transition.

I became interested in the relationship between project coordination and engineering quality through work on web applications and research I co-authored in 2023 on a Scrum–XP hybrid for distributed web development. The question that remains useful to me is not whether Scrum or Extreme Programming is the better label. It is how a team’s definition of completed work becomes something it can demonstrate.

Scrum does set a quality expectation

It would be inaccurate to say Scrum is concerned only with meetings and deadlines. The 2020 Scrum Guide explicitly holds Developers accountable for quality through a Definition of Done and states that quality must not decrease during a Sprint. It treats the Definition of Done as the formal description of the state of an Increment when the product’s required quality measures have been met.

That commitment creates a shared understanding of what complete means. Work that does not meet the Definition of Done is not part of a Done Increment, even if development effort has already been spent. The Increment should be usable, and a Sprint Review is an opportunity to inspect and adapt—not a substitute for completing quality work beforehand.

Scrum is deliberately lightweight about how a team achieves those conditions. It does not require test-driven development, pair programming, a particular CI service, or a fixed test-coverage percentage. Teams must choose appropriate techniques for their product, capabilities, and risks.

This is the first important distinction: Scrum establishes accountabilities and transparency around quality; it does not supply every engineering practice needed to meet those commitments.

A Definition of Done is not a substitute for feature behavior

Imagine a team adding a discount-code field to an e-commerce checkout. This is an illustrative example, not a report of a client implementation.

The feature could satisfy a visual design and still fail its purpose. A valid code should produce the discount the server accepts. An expired code should not change the total. The user should understand why a code was rejected. The new interaction should remain operable with a keyboard and should not disturb the ordinary checkout path.

These are product-specific examples of what that feature must do. They are distinct from a team-wide Definition of Done, which might require integrated code, appropriate reviews, verification of relevant behavior, and necessary documentation. The two levels should reinforce one another: the acceptance conditions define the feature’s intended outcome; the Definition of Done provides the baseline quality standard for the Increment.

Writing either one is only the beginning. A team needs to decide what evidence would justify saying those conditions were met, especially when the outcome depends on more than one system.

Connect each quality expectation to an observable check

A useful approach is to take each important quality claim and ask how someone could verify it. For the hypothetical checkout change, the team might establish the following connections. The engineering practices are illustrative choices, not mandatory Scrum rules.

The table separates three things that are often collapsed into one: the quality expected, the practice intended to support it, and the evidence that the practice actually covered the relevant behavior.

For example, a test named “discount works” is not especially informative by itself. The stronger evidence is that the test exercises a valid code, verifies a server-confirmed total, and has an appropriate negative case. The test may still miss other defects, but it is at least connected to a specific product risk.

Engineering practices make the quality commitment repeatable

Extreme Programming offers practices such as automated testing, test-driven development, refactoring, pair programming, and continuous integration. They are complementary techniques, not a single package a Scrum team must adopt without judgment. Their value lies in what they help teams detect or improve.

Tests can turn important behavior into repeatable checks. Refactoring supported by reliable tests can improve the internal design without deliberately changing externally observable behavior. Pair programming or focused review can expose assumptions before they become widely depended upon. None of these practices guarantees defect-free software; each provides a different form of feedback.

Continuous integration deserves particular care. In Martin Fowler’s definition, developers integrate their work into a shared mainline frequently—at least daily—and each integration is checked with an automated build and tests. A service that runs tests on a long-lived branch is useful, but that alone does not prove the branch has been fully integrated with colleagues’ changes. The shared state also needs verification.

A green pipeline only proves that the checks it ran passed in the environment and version they examined. If a test never exercises the rejected discount code, or if important checkout behavior is absent from the checks, the green indicator cannot answer those questions. Automation increases the frequency and consistency of feedback; its quality still depends on what the team chooses to verify.

For a concrete example of putting verification at the right boundary, Testing Shared UI Components Without Testing Every Page Twice distinguishes component checks from integration and journey checks.

Distinguish reassuring signals from meaningful evidence

A team may have several positive-looking signals without enough information to support a release decision. These are common examples of what each signal can and cannot establish.

The goal is not to dismiss boards, reviews, dashboards, or coverage reports. Each has a legitimate use. The mistake is asking a process signal to stand in for a product conclusion it cannot support.

For instance, an automated build can tell us whether integrated code compiled and passed a defined test suite. It cannot tell us whether every business rule was correctly understood. A Sprint Review can make the product and feedback visible. It cannot retroactively transform incomplete quality work into a Done Increment.

Distributed teams need evidence that travels with the work

The distinction becomes particularly useful when contributors work across locations or schedules. Someone reviewing a change may not have watched the feature being built or been part of the conversation that clarified its behavior.

Good handoff information should survive that distance. A reviewer needs to know what changed, which assumptions matter, how the important behavior was checked, which environment or version was used, and what uncertainty remains. A passing test link, a reproducible failure case, or a concise explanation of an integration dependency can be more valuable than a status message saying the task is finished.

In the checkout example, imagine one developer implements the field while another maintains the pricing service. The critical question is not whether both tasks have separate approvals. It is whether the version being considered for release correctly combines the frontend interaction, server validation, confirmed totals, and rejected-code behavior.

This does not require heavyweight documentation for every change. For a narrow wording update, normal review may provide sufficient confidence. Where several services or teams contribute to one user-visible outcome, the cost of an ambiguous handoff is higher, so the evidence should be more explicit.

A quality standard should shape planning, not appear at the end

A Definition of Done becomes impractical if the team plans only implementation work and discovers near the end of the Sprint that integration, verification, and correction require significant additional effort.

For important changes, the team should account for the work needed to meet its quality standard while refining and planning the item. If the discount-code behavior depends on a pricing API, that integration and its failure states are part of the job—not optional follow-up once the interface looks complete.

When new risks become visible, the team can adapt its plan and clarify scope. It should not silently weaken the quality threshold to preserve an optimistic progress report. The Scrum Guide permits scope to be clarified and renegotiated within a Sprint; it does not frame reducing quality as the way to meet a Sprint Goal.

The trade-off is still real. Not every feature needs exhaustive UI automation, every XP practice, or the same depth of investigation. The team should choose where additional verification is warranted by impact, complexity, and existing coverage. Engineering judgment determines the appropriate technique; the commitment to usable quality should remain clear.

What I would ask before calling an Increment Done

Instead of asking only whether a ticket’s subtasks are complete, I would ask whether the affected behavior was checked in the integrated product, whether the most consequential failure paths were considered, whether existing important behavior was protected, and what evidence supports the team’s claim.

A useful follow-up is whether another engineer could explain or reproduce that evidence without relying on the original developer’s memory. If the answer is no, the issue might be missing tests, unclear assumptions, an integration gap, or simply a poorly documented verification step. Those are different problems and deserve different responses.

These questions also prevent a Definition of Done from becoming a decorative checklist. A quality standard is valuable only if the team can connect it to real work and can recognize when the available evidence is insufficient.

Quality is a commitment—and a capability

Scrum provides a structure for making work, progress, and quality commitments transparent. Engineering practices provide ways to build, integrate, inspect, and improve the software against those commitments. They are not alternatives competing for the same role.

The point is not to combine Scrum and XP because a hybrid sounds more sophisticated. It is to ensure that the team’s chosen engineering practices are capable of supporting what it promises when it says an Increment is Done.

A Sprint ending on time tells us something about coordination. A usable Increment backed by relevant evidence tells us something more important about delivery. Mature teams need both.