Scrum, day 38: making work understandable

Today's objective: identify the conversation an unclear Product Backlog item needs before it can support a credible delivery decision.

Read alongside: Mastering Professional Scrum, chapter 5, focusing on refinement; revisit Scrum: A Pocket Guide, fourth edition, §3.3 if useful. Allow roughly five minutes for this companion, plus the reading.

A complete template can still conceal an unclear idea

The fictional ShiftSwap backlog contains an item titled “Smart notifications.” It has a user-story sentence, a priority label, and an estimate. The form is complete, but the Developers imagine different behavior.

One expects a reminder for every pending request. Another expects a single handover summary. Elena expects alerts only when responsibility changes. A colleague worries about repeated messages after a request is cancelled.

Refinement should expose these differences before the team relies on an apparent agreement. Adding more fields to the template will not help unless the information makes the intended result and important boundaries easier to understand.

Start with the problem and the person

Elena describes the observed difficulty: an incoming supervisor sometimes fails to recognize a decision that now needs their attention. The team distinguishes that problem from a separate concern about repeated irrelevant messages.

This gives the item a clearer purpose. It also narrows the discussion. The team can focus on one situation involving changed responsibility instead of designing a universal notification engine.

The purpose should be understandable to the people doing the work. Developers can often suggest a simpler approach once they know what the user needs. If they receive only an implementation instruction, that opportunity is harder to see.

Use examples to reveal boundaries

The team walks through three cases: a pending request during an ordinary handover, a request resolved before the new supervisor arrives, and a request cancelled just as responsibility changes.

The first case explains the intended benefit. The others reveal where an indiscriminate alert would be misleading. The discussion also exposes a prerequisite: the product needs a reliable way to determine who currently holds the relevant responsibility.

These examples make the item more precise without specifying every technical detail. The Developers can still choose an implementation. The team has clarified the behavior and uncertainty that the implementation must address.

Separate a missing decision from a missing fact

Does the café already have a rule for who handles requests during overlapping supervision? If so, the team needs to discover and understand it. If no agreed rule exists, someone with appropriate product and operational authority needs to help decide it.

Treating both situations as “requirements missing” can obscure the next action. Researching an existing practice differs from making a new product choice. The people needed and the evidence required may differ too.

The team records the unresolved question and a concrete next step. “Ask about responsibility during overlap” is more useful than moving the item into a generic blocked category with no owner or follow-up.

Split around a useful result

The original smart-notification idea may contain several capabilities: identify current responsibility, show pending decisions, send an alert, suppress stale alerts, and allow personal preferences. Some are dependencies; others may be optional extensions.

The team looks for a smaller coherent result that can be completed and inspected. Perhaps an explicit handover summary using reliable current information would provide useful evidence before automatic alerts are added.

Splitting should preserve honesty about what a user can do. A database field alone may be a necessary task, but it does not provide the promised notification benefit. The team can organize internal tasks while keeping the product-level slice clear.

Use sizing differences as information

When Developers discuss the effort, their estimates differ. One assumes responsibility data already exists and is dependable. Another includes investigating and correcting it. The disagreement reveals incompatible assumptions rather than a problem to solve by averaging numbers.

The team can clarify the assumption, narrow the item, or plan a bounded investigation. The resulting size may still be uncertain. The useful improvement is a shared understanding of what drives that uncertainty.

Scrum.org's Product Backlog reference describes refinement as ongoing work to make items smaller and more precise. A locally chosen sizing method should support that understanding, rather than become the purpose of the conversation.

Stop when you can make the next decision responsibly

Refinement does not need to eliminate every uncertainty before implementation. Some questions can only be answered by building, integrating, or observing a real interaction. The team should identify those questions rather than invent answers to make the item appear ready.

For an item likely to enter a Sprint, the Developers need enough understanding to judge whether it can be completed within the Sprint while meeting the quality standard. They also need a useful purpose and a way to address the remaining uncertainty.

A rigid local entry checklist can help prompt questions, but it should not become a handoff contract that prevents collaboration once work begins. Understanding continues to develop during delivery.

Refine one unclear item

Choose an item whose title could support several interpretations. Write the intended user benefit, one ordinary example, one boundary case, and the most consequential unresolved question.

Decide whether the missing information requires discovery, a product decision, or implementation learning. Propose a smaller slice if the current item contains several independent outcomes. Then explain what remains uncertain and how the team will handle it.

Reflection: if two Developers described this item independently, where would their assumptions most likely diverge? That is a useful place to begin the next conversation.

Next, day 39 uses this understanding to make a Sprint forecast.