Scrum, day 31: quality throughout delivery

Today's objective: move useful quality information earlier in the work while retaining the verification needed for the complete product.

Read alongside: Mastering Professional Scrum, chapter 3, focusing on quality practices and quality measures. Allow roughly five minutes for this companion, plus your book reading.

The expensive part is discovering the assumption late

The fictional ShiftSwap team checks a new pending-request view near the end of a Sprint. The interface looks correct, but keyboard navigation cannot reach an important action. Fixing the problem requires changing a shared component already used in several places.

The team could respond by reserving more time for a final accessibility check. That might help detect similar problems before release. It would leave the same late discovery pattern in place, however: several decisions would still depend on an unsuitable component before anyone examined the interaction.

Quality throughout delivery means asking which information could influence those decisions earlier. The team still needs to verify the integrated result. Earlier feedback and final verification serve related purposes at different points in the work.

Find the decision that needed the information

The important choice happened when the Developers selected the interaction pattern. At that point, a simple keyboard walkthrough of the component could have revealed the issue. The whole feature did not need to exist yet.

For the request-state problem from earlier lessons, the corresponding early information was a sequence of events: the manager opens a request, the employee cancels it, and the manager attempts approval. Discussing that example could expose a missing service rule before implementation.

Different risks require different observations. An automated check of a calculation, a review of an interaction, and a realistic test of a message sequence answer different questions. “Test earlier” becomes useful when the team can identify the decision and the evidence it needs.

Turn a risk into a concrete check

ShiftSwap takes the broad concern “managers must be able to use the pending list” and identifies several examples. A manager uses only the keyboard. Another has a long request description. A request changes state while the page remains open.

The Developers decide which examples can inform design, which can become automated checks, and which need examination in the integrated product. They avoid assuming that one technique covers every concern.

For example, an automated check may confirm that a cancelled request cannot be approved. It does not establish whether the manager understands the response. A conversation with a manager may reveal confusing wording, but it does not prove that concurrent actions preserve the correct state. The evidence should match the claim.

Make quality work part of the delivery plan

If the plan contains only implementation tasks, other necessary work can appear to be an unexpected interruption. The Developers should include the effort needed to meet the shared quality standard when deciding what they can complete.

For the pending list, that includes preparing examples, checking permissions, integrating the behavior, and examining the important interactions. Some activities can overlap; others depend on usable behavior being available. Making them visible helps the team coordinate across skills.

This does not require an elaborate checklist for every minor change. The plan needs enough detail to support a credible forecast and reveal important dependencies. Its purpose is to help the Developers finish, rather than document every keystroke.

Choose measures that provoke investigation

The team considers counting defects discovered after release. That can reveal an important quality problem, but the number needs context. A small wording issue and a misleading approval state have different consequences. Changes in reporting practices can also change the count without changing the underlying product.

ShiftSwap therefore records a brief account of consequential failures: the user impact, where the relevant assumption entered the work, where the issue was detected, and what could help prevent or detect a similar problem earlier.

Patterns in those accounts can guide improvement. Repeated failures around request transitions suggest a different response from repeated misunderstandings about employee-facing language. A single aggregate number can hide that difference.

Do not turn a measure into a reason to hide problems

Suppose colleagues are praised for reporting the fewest defects. Someone who investigates carefully may appear less successful than someone who leaves problems unexplored. The measure can reward the opposite of the behavior the team needs.

Likewise, a target for the number of automated checks can encourage easy checks that add little confidence. Coverage information may help locate unexamined behavior, but a percentage cannot by itself establish that the important risks are addressed.

The team should ask how a measure could improve while the product became worse. That question exposes incentives and blind spots before the number becomes a performance judgment. Quality evidence works best when people can report uncomfortable findings without having to protect a personal score.

Keep responsibility shared and expertise visible

A colleague with verification expertise can help the team design better examples and recognize gaps. That does not make quality exclusively their responsibility. Developers making implementation choices need to understand how those choices will be checked and maintained.

At the same time, shared responsibility should not erase specialist knowledge. Asking everybody to care about accessibility is useful; assuming that caring makes everybody equally skilled at evaluating it is not. The team can combine learning, consultation, and focused expertise.

The aim is a delivery process in which useful quality information reaches the relevant decision, and the finished product has evidence supporting its completion claim.

Move one check earlier

Choose a defect or usability problem discovered late. Trace it to an earlier assumption or decision. Describe a small check or conversation that could have challenged that assumption before other work depended on it.

State what the earlier check would establish and what still needs verification in the complete product. Then choose one observation that would help evaluate the change over the next few relevant items. Include the cost of preparing and maintaining the check.

Reflection: which quality question does your team postpone until the answer is expensive to act on? Identify the earliest point at which you could obtain useful evidence, even if complete certainty remains impossible.

Next, day 32 examines quality-related constraints that accumulate over time.