Scrum, day 18: a Retrospective with an experiment

Today's objective: turn a recurring complaint into a specific improvement the team can try and evaluate.

Read alongside: Scrum.org's Sprint Retrospective reference and Scrum: A Pocket Guide, fourth edition, §2.5, focusing on the Retrospective. Allow roughly five minutes for this companion, plus the assigned reading.

Begin with something that actually happened

The fictional ShiftSwap team has completed its Sprint Review. It now examines how it worked during the Sprint. The decline flow became usable, but the old-record problem caused a late change in the plan. Several people felt rushed during verification.

Someone writes “testing always happens too late.” Another adds “we need better requirements.” Those comments express frustration, but neither gives the team a clear experiment to try. They could produce the same discussion again next Sprint.

The team selects one actual sequence to examine: when it first learned that older decline records contained internal notes, which decisions had already been made, and what work changed afterward.

The Sprint Retrospective reference describes an event for improving quality and effectiveness. Looking at a concrete sequence helps the team connect that purpose to its own circumstances.

Reconstruct the sequence before assigning a cause

The team draws a short timeline from planning to completion. At planning, participants discussed a recent declined request. During implementation, they used newly created records. On the fifth working day, a check with older data exposed the different note format.

The test specialist had asked about representative data earlier but assumed someone else was arranging it. The service Developer assumed all records relevant to the pilot used the recent format. Elena understood the intended employee experience but did not know that the data representations differed.

There is no need to invent a single careless person to explain this sequence. Several assumptions interacted. The team can examine them while still expecting each person to explain their decisions honestly.

A statement such as “the legacy-record question had no clear next action after planning” points toward something the team might change. “Testing is slow” does not explain the same evidence.

Choose a change within reach

The team considers several options. It could rewrite every backlog item, create a large catalog of historical data, add another approval meeting, or try a smaller change in how it examines state-changing work.

It chooses the smaller experiment. For the next two relevant changes, before settling on an implementation approach, a pair of Developers will work through examples using a recent record, an older record, and an exceptional state. They will involve Elena or a manager when an example exposes a product-policy question.

This is a locally chosen practice, not a mandatory Scrum checklist. Its purpose is to reveal consequential assumptions earlier. The team can adjust it if the three examples turn out to be irrelevant to some kinds of work.

The experiment should also fit within real capacity. If it requires time from someone who is unavailable, the plan needs to account for that rather than relying on goodwill after working hours.

Make the experiment evaluable

The team writes a short record:

We believe examining representative record states together before implementation will expose important behavior differences earlier. We will try it on the next two changes involving request state. We will record what questions it reveals, how much effort it takes, and which differences are still discovered later.

Two Developers volunteer to arrange the first session. The team adds the improvement work to its visible plan and agrees to inspect the experience at the next Retrospective, while discussing any immediate problems sooner.

The measures are modest. The team does not expect two examples to prove a permanent increase in productivity. It wants enough information to decide whether the practice is useful, needs revision, or is not addressing the real cause.

Counting completed example sessions alone would be weak evidence. The practice could be performed perfectly while revealing nothing useful. The team needs to examine the decisions and rework it was meant to influence.

Preserve what helped as well

The Retrospective also identifies a useful response during the Sprint: the Developers noticed the shared obstacle at the Daily Scrum and reorganized around it. That helped the team finish a coherent result instead of allowing several components to remain separately “almost done.”

The team wants to keep that behavior. An improvement conversation focused only on problems could accidentally dismantle a practice that was helping.

It also checks whether the response carried a hidden cost. Did one person absorb all the extra work? Did another important obligation disappear from view? Understanding those consequences prevents a successful rescue from becoming an unsustainable routine.

Take a broader obstacle to someone who can change it

Suppose the experiment reveals that representative data cannot be obtained because a shared environment is unavailable for days. The team can adjust how early it asks, but it may still need organizational help.

Radu can help make the dependency and its consequences visible to the group responsible for the environment. The improvement record should distinguish what the team will do from the decision it needs elsewhere. Repeatedly assigning “resolve environment problem” to a Developer without authority would not create progress.

The Retrospective can reveal such an obstacle. It does not make the Scrum Team solely responsible for conditions it cannot control, nor does it justify giving up on the parts it can improve.

Leave with a practical next step

The whole Scrum Team participates in the Retrospective, including the Product Owner and Scrum Master. Its timebox is at most three hours for a one-month Sprint and is usually shorter for shorter Sprints. The team chooses a format that supports useful inspection and adaptation within that boundary.

In this case, one experiment is enough to make a worthwhile next step. Scrum does not mandate exactly one action or a particular template. The team should choose improvements it can actually pursue and inspect, rather than produce a large action list that no one revisits.

Improvements can be made during a Sprint too. The Retrospective provides a recurring place to examine the broader pattern; it should not become a reason to postpone an obvious useful correction.

Convert a complaint into an experiment

Choose a recurring complaint and attach it to one observed incident. Describe the sequence, the assumptions involved, and the consequence. Propose a change small enough to try with the people and authority available.

Write what you expect to improve, who will take the first action, and what you will inspect afterward. Include one observation that would make you stop or revise the experiment.

Reflection: could your action be marked complete without anything improving? If so, add a question about the effect it is meant to have.

The next companion examines how Scrum's artifacts make the state of the work visible enough to support these conversations.