Scrum, day 27: a shared quality boundary

Today's objective: make an ambiguous completion claim testable by identifying the quality evidence needed for a usable product Increment.

Read alongside: Mastering Professional Scrum, chapter 3, focusing on the Definition of Done, and Scrum.org's current explanation. Allow roughly five minutes for this companion, plus your book reading.

Ask what “tested” actually means

The fictional ShiftSwap team has built a manager view that recognizes a cancelled request. A Developer says the work is tested. Another asks whether that includes cancelling the request after the manager has already opened it. The first person checked only requests that were cancelled before the page loaded.

Both acted in good faith. Their completion claim still concealed an important difference. A green test result meant one thing to the person who ran it and something broader to the people using it to decide whether the product was ready.

A shared quality boundary should make those differences easier to discover. It gives people a common meaning for Done that is tied to the product they are actually creating.

Distinguish a particular behavior from the shared standard

This item needs a specific behavior: an outdated approval attempt must not turn a cancelled request into an approved exchange, and the manager must receive an understandable response. Those examples help define what this change is intended to do.

The Definition of Done addresses the quality state of the Increment more broadly. ShiftSwap might require changed behavior to be integrated, relevant automated checks to pass, important user interactions to be verified, and operational effects to be understood. The exact measures must fit the product and its organizational standards.

An item's examples and the shared quality standard complement one another. Passing the cancellation example alone does not establish that the change works with the rest of the product. Conversely, a generic statement that “all checks passed” does not establish that the team implemented the intended behavior.

Replace vague claims with inspectable evidence

The team examines three phrases in its current completion checklist:

These directions still require judgment. A good standard does not enumerate every possible check for every future change. It provides enough clarity that people can agree on the evidence appropriate to the work and challenge gaps before calling it Done.

Include the behavior between components

For the cancelled request, checking the interface and service separately leaves a gap. The team needs to examine the sequence in which the manager sees old information, the service receives an action, and the current request state determines the response.

A small automated check may cover the service rule. An interaction check may cover the explanation shown to the manager. Another check may establish that no misleading approval message is sent. Together, these provide evidence about the connected product behavior.

The team should be able to explain why these checks matter. A large count of passing checks can coexist with an unexamined failure path. The quality conversation concerns the product's risks and required behavior, not the prestige of a particular tool or the size of a test report.

Make unfinished work visible without relabeling it

Suppose the interface behavior is complete but the service still accepts an outdated approval. The team cannot solve the discrepancy by marking the item Done and opening a follow-up ticket for “hardening.” The original capability remains unreliable.

Scrum.org's Definition of Done reference explains the boundary: work that does not meet the standard cannot be treated as part of the Increment. The team can discuss its actual state and the remaining work honestly, including why its forecast proved inaccurate.

This distinction supports useful decisions. Elena can explain what is available and what is still uncertain. The Developers can decide how to address the gap. Stakeholders can respond to the actual product rather than a label that overstates its readiness.

Improve the standard without turning every discovery into bureaucracy

The cancellation example may reveal a recurring weakness in how the team checks changes across request states. That could justify clarifying the shared standard. It does not follow that the Definition of Done should contain the entire cancellation script word for word.

A lasting requirement might concern verifying relevant state transitions and their effects across the product. The specific examples can remain with the item and its checks. This keeps the standard useful for later changes while preserving the evidence for this one.

The team should also avoid adding a broad requirement that it cannot explain or satisfy. “No defects” is not a practical description of demonstrable quality. Concrete expectations make the remaining uncertainty easier to discuss.

Understand who shares the boundary

The standard belongs to the product work, rather than to the personal preference of whichever colleague checks an item last. Applicable organizational standards form a minimum. Where several Scrum Teams work on one product, they need a common Definition of Done.

Within ShiftSwap, Elena benefits from understanding the standard because it shapes what the team can credibly claim and forecast. The Developers must satisfy it. Radu can help expose a gap between the documented standard and what people actually do.

If an expectation is routinely skipped, the team needs to investigate the discrepancy. It may need better tools, skills, access, or a clearer interpretation. Quietly ignoring it preserves an appearance of quality while removing the shared basis for trust.

Test one completion claim

Take a recent item described as finished. Write its intended user behavior, the relevant quality expectations, and the evidence that each was satisfied. Ask a colleague to interpret the same completion claim independently.

Compare the interpretations. Choose one ambiguous phrase and replace it with a statement that makes the expected evidence clearer. Then check whether the revised wording belongs in the product's shared standard or in the examples for this particular item.

Reflection: what could a stakeholder reasonably assume from the word Done today that your team's evidence does not yet support? That gap is a useful starting point for improving transparency.

Next, day 28 uses a Sprint Goal to navigate a scope trade-off while preserving quality.