Scrum, day 33: defining useful results

Today's objective: distinguish completing a feature from improving a user's situation, then describe evidence that could connect the two.

Read alongside: Mastering Professional Scrum, chapter 4, focusing on value and delivery speed. Allow roughly five minutes for this companion, plus the book section.

A release is an achievement with an unanswered question

The fictional ShiftSwap team releases its manager handover view. The change meets the Definition of Done, works with the existing product, and arrives earlier than the team initially expected. Those are meaningful achievements.

Elena still needs to answer another question: does the view help the incoming supervisor identify and resolve pending requests without reconstructing conversations? A technically sound feature may be difficult to discover, irrelevant to the busiest handover, or based on an incorrect assumption about the manager's problem.

Delivery creates the opportunity for benefit. It does not establish that the benefit occurred. The team needs a description of the desired result that reaches beyond the feature itself.

Describe the change in the user's situation

“Add a pending-request dashboard” describes a solution. “Reduce the need for an incoming supervisor to ask the previous supervisor which swaps still need decisions” describes a change in work.

The second statement makes several assumptions visible. Managers must be able to recognize the relevant requests. The information must be current enough to act on. The workflow must fit the way a handover happens. The manager must know the capability exists.

These assumptions suggest what to investigate. They also leave room for a simpler solution. Perhaps a dependable view of current requests is sufficient without a configurable dashboard, reminders, and a collection of charts.

Separate several kinds of evidence

The Evidence-Based Management Guide distinguishes what an organization invests, does, produces, and achieves for users. Applied to this example, Developers' time is an input, implementation is activity, the released view is output, and a more dependable handover is an intended outcome.

Those categories help prevent a misleading substitution. More implementation activity does not establish more user benefit. More releases may increase opportunities to learn, but the team still needs evidence about what changed for the people using them.

For ShiftSwap, a release record can establish availability. An observation of a manager completing a handover can reveal usefulness. Support conversations can expose remaining confusion. Each source answers a different question.

Write a result that can be challenged

Elena proposes: “At the two pilot cafés, incoming supervisors can identify the requests awaiting their decision from ShiftSwap without needing the previous supervisor to reconstruct the list.”

This is specific enough to challenge. A supervisor who repeatedly needs the old conversation history provides evidence that the intended result is incomplete. A supervisor who can identify the list but cannot safely act on it reveals a different gap.

The statement is also bounded. It does not claim that the feature eliminates all handover communication or solves every staffing problem. Useful goals should leave room for ordinary human coordination rather than treating every conversation as waste.

Look for unintended effects

A new view could make pending requests easier to find while encouraging supervisors to decide too quickly without understanding a qualification constraint. It could reduce handover messages but leave employees uncertain about why a request was declined.

The team should consider these possibilities before declaring success from one favorable measure. A faster decision is not necessarily a better decision. Fewer messages may reflect clearer information, but they may also reflect people giving up or moving to a different channel.

Choose a small number of related observations that make the interpretation more credible. For this example, Elena might examine whether requests are identified correctly, whether managers can explain their state, and whether employees still receive understandable outcomes.

Treat early feedback as a reason to investigate

Suppose three managers try the view and two describe it as helpful. That is useful feedback, but it does not prove the intended outcome across all handovers. The setting may have been unusually quiet, and the third manager's difficulty may reveal an important case.

The team can ask what each person actually did, which information they used, and where they needed help. It can observe later handovers under ordinary conditions and compare them with the original expectation.

Small observations can guide sensible next steps without supporting broad numerical claims. The team should preserve that distinction when communicating with stakeholders who may be eager to describe the pilot as an established success.

Let the result influence the next investment

If the view helps managers but employees still misunderstand final approval, the next useful change may belong in the employee experience. If managers cannot distinguish similar requests, the team may improve context before adding automatic filters.

This is where outcome thinking becomes operational. It changes what Elena orders next and what the team investigates. Recording user benefit in a presentation while continuing an unchanged feature list would leave the central decision process untouched.

The team can also decide to stop expanding a capability when the relevant need is sufficiently addressed. Continuing to add features is not automatically progress if the original problem no longer justifies the effort.

Rewrite a feature request

Choose a feature from a backlog. Describe the person it is intended to help, their current difficulty, and the improved situation you expect. List two assumptions connecting the feature to that outcome.

For each assumption, identify an observation that could support or challenge it. Include one possible unwanted effect. Then ask whether a smaller change could provide useful evidence before the full feature is built.

Reflection: what would you do if the feature shipped successfully but the user's situation did not improve? Naming that possible decision now makes the outcome more than a decorative ambition.

Next, day 34 connects a small change with the product's broader direction.