~/vladvisinescu_
<- cd ~/tutorials

tutorial

Scrum, day 34: connecting work to purpose

Today's objective: connect a small product change with a broader ambition through explicit assumptions that the team can inspect.

Read alongside: Mastering Professional Scrum, chapter 4, focusing on product vision and team purpose. Allow roughly five minutes for this companion, plus the book reading.

The missing explanation between a button and a vision

The fictional ShiftSwap team receives a request to make an approval button more prominent. The product's broad ambition is to help café employees arrange shift exchanges with confidence. The button change might support that ambition, but the connection is not obvious merely because both concern the same application.

Elena asks what problem prompted the request. A manager explains that incoming supervisors sometimes overlook pending decisions during handover. The team now has a situation to investigate rather than an isolated visual instruction.

Connecting work to purpose means explaining the chain from a change to a useful effect. It also means admitting where that chain rests on assumptions rather than evidence.

Use different levels of purpose for different decisions

The broad product ambition describes a lasting direction. The current Product Goal focuses on employees at the first two cafés arranging eligible swaps and understanding when they are final. A Sprint Goal can focus on one useful step, such as helping an incoming supervisor act on pending requests reliably.

The proposed button change sits within that smaller context. It should be evaluated by whether it helps the relevant interaction, not by whether its wording can be loosely associated with the broad ambition.

A team does not need an elaborate hierarchy of objectives for every task. It does need enough connection that people can explain why the work matters and recognize when a new request pulls attention away from the current focus.

Make the causal story visible

For the button request, the team writes a short explanation: a clearer action may help managers notice a pending decision; noticing it may help them resolve it during handover; a timely decision may help employees know whether their swap is final.

Each “may” matters. A more prominent button will not help if the manager never opens the page. A quick decision may be inappropriate if the request lacks necessary context. A correct decision may still leave the employee uncertain if the final state is poorly communicated.

The explanation therefore identifies several places where the proposed solution could fail to create the intended benefit. That is useful information for choosing what to observe before investing further.

Compare another route to the same outcome

The Developers discover that the action is already easy to find once a manager opens the request. The more common difficulty is recognizing which requests need attention at all. Improving the list's status information may address that problem more directly than changing the button.

Elena can compare the options through the intended outcome. She does not need to defend the original request simply because it was the first solution proposed. The manager who requested the button may also prefer the alternative once the underlying problem is understood.

This is one reason to preserve the problem statement alongside the solution. If only the requested implementation survives, later discussions can become arguments about compliance rather than conversations about whether the work will help.

Notice when the connection is too weak

Another stakeholder proposes a branded animation after approval, arguing that it will make ShiftSwap feel more polished and therefore increase confidence. That is a possible hypothesis, but the team has little evidence that visual polish is the current obstacle to confidence.

Employees have instead reported uncertainty about whether colleague acceptance means final approval. A clearer state explanation has a more direct connection to the observed difficulty. The animation can remain an idea without displacing the more relevant work.

This does not establish a permanent rule against polish. It establishes why one choice appears more useful in the current circumstances. If later observations reveal that an interaction feels unreliable despite correct information, presentation may deserve renewed attention.

Include internal work in the explanation

The status-rule consolidation from day 32 has no obvious new button or screen. Its connection to purpose runs through the team's ability to make consistent changes and keep different product surfaces in agreement.

That explanation should be concrete enough to inspect. The team expects fewer conflicting interpretations and less repeated work when changing request behavior. It can examine those effects during subsequent changes.

Internal work does not need an invented user story to be legitimate. It needs an understandable relationship to the product's quality, operation, future options, or delivery capability. Some work supports value indirectly, and the team should explain that route honestly.

Revisit the chain when the environment changes

Suppose the cafés change their handover procedure so the outgoing supervisor must resolve most requests before leaving. The incoming manager's list may still matter, but the original assumptions about its use have changed.

The team should inspect the effect on its priorities. A previously sensible feature could become less useful. A different point in the workflow may now create the main uncertainty. Continuing unchanged because the work once aligned with the vision would ignore the evidence that alignment was meant to support.

Purpose provides direction under change. It should help the team reconsider its route, rather than become a slogan used to justify decisions after the fact.

Draw one short chain

Choose an item and write four connected statements: the change, the behavior it may enable, the user outcome, and the broader goal it supports. Keep the statements concrete enough that someone could disagree with an assumption.

Mark the least certain connection. Identify a small observation or experiment that could inform it. Then propose an alternative change that might produce the same outcome and compare the two using what you currently know.

Reflection: if you cannot explain how an item contributes to the current direction, is the explanation missing, the item misplaced, or the direction too vague? Decide which conversation would resolve that uncertainty.

Next, day 35 examines how to observe outcomes without overclaiming what the numbers mean.

  1. 01 Scrum, day 60: choosing your next experiment
  2. 02 Scrum, day 59: reconciling the books
  3. 03 Scrum, day 58: inspecting the change itself
  4. 04 Scrum, day 57: moving beyond one team
  5. 05 Scrum, day 56: building lasting capability