Scrum, day 06: evidence that changes the plan

Today's objective: connect a visible observation to an inspection question and a concrete adaptation, while stating what the evidence cannot establish.

Read alongside: Scrum: A Pocket Guide, fourth edition, §2.6, “Core principles,” and Scrum Theory in the Scrum Guide. Allow roughly five minutes for this companion, plus the assigned reading.

Start with a result that seems obvious

The fictional ShiftSwap team has revised its approval-status display. In an invented pilot exercise, eight of ten employees can now explain whether a swap is final without asking for help. In the earlier exercise, four of ten could do so.

Someone puts a green arrow beside the numbers and proposes rolling the product out to the remaining cafés. The result looks encouraging. Before making that decision, however, the team needs to know what those two counts mean.

Were the same people involved? Did they remember the task? Did a facilitator offer hints? Were employees looking at a genuinely pending request or a simpler completed one? Did the exercise include the evening supervisor's approval policy? The counts alone cannot answer these questions.

Empiricism means using experience and observation to guide decisions. The Scrum Guide connects it to transparency, inspection, and adaptation. In this example, those three ideas can be followed through one decision about expanding the pilot.

Make the observation understandable

The team replaces the isolated green arrow with a short record of the exercise. It includes the task participants attempted, how help was recorded, which version they used, and the conditions under which they tried it. It also includes the two cases where people still misread the status.

That record reveals a limitation: all ten participants work at the same café. None used the evening-supervisor arrangement discovered in day 04. Several participants had seen the first version before. The improved count remains useful, but its meaning is narrower than the initial presentation suggested.

Transparency requires people to understand the work and its actual state well enough to make decisions. It involves more than making a dashboard accessible. If a green status means “the screen was implemented” to one person and “employees can reliably use the flow” to another, everyone can see the dashboard while still acting on incompatible information.

The team agrees to distinguish those claims. The product change meets its shared quality standard; the pilot observation concerns how this particular group understood it. Completion and user benefit answer different questions.

Inspect against a question

The Product Owner asks: “Do we have enough evidence to introduce this flow at a café with a different approval arrangement?” That question is more useful than asking whether the new number is good.

The team examines the two unsuccessful cases. One employee interprets a colleague's acceptance as the final decision. Another understands the status but cannot find the manager's reason for declining. Those observations suggest different problems and potentially different changes.

It also considers another explanation for the apparent improvement: returning participants may have learned the exercise. The team does not need to dismiss the result or conduct a large study before doing anything. It does need to avoid claiming that the revised interface alone caused the difference.

Inspection becomes useful when people can connect evidence to a choice. Here, the remaining uncertainty is sufficiently specific to guide the next pilot: include people unfamiliar with the product and use the second café's real approval arrangement.

Choose an adaptation small enough to evaluate

The team postpones a broad rollout and prepares a bounded second-café pilot. It retains the clearer status display, adds a visible explanation for a declined request, and checks the supervisor handover. It records why each change was selected.

These are working interpretations. The team should revise them if the next observations point elsewhere. Stating an interpretation explicitly makes it easier to notice when it is wrong.

Close the loop at the right time

The team records who will arrange the next pilot and when it will examine the result. Otherwise, “we should learn more” could remain an indefinitely postponed intention.

Scrum provides recurring inspection and adaptation opportunities. In this scenario, the Sprint Review can bring the usable product, pilot observations, and stakeholder needs into the discussion about what comes next. The Developers can use the Daily Scrum to adapt their delivery plan, and the team can examine the quality of its investigation in the Retrospective. These conversations serve different purposes; presenting the same dashboard in each one would not make them equally useful. The Scrum.org introduction to the events provides a reference for those distinctions.

Feedback can also arrive between events. If the team discovers that an employee is acting on an incorrect approval, it should address that information promptly. A scheduled conversation gives inspection a reliable place; it does not make waiting for that conversation a virtue.

Build an evidence-to-decision note

Choose a claim from your work, such as “the new flow is easier” or “our review process is faster.” Write what was observed, how it was observed, and one plausible alternative explanation. State the decision the evidence is meant to support.

Then choose a next action. It might be changing the product, investigating a specific uncertainty, or keeping the current approach because the evidence does not yet justify the cost of changing it. Include a time to inspect the result.

Reflection: what finding would make you reverse your preferred decision? If no observation could change your mind, reconsider whether you are investigating the question or simply defending a conclusion.

The next companion connects this feedback loop to the Scrum framework as a whole, using one Sprint in the same fictional product.