Scrum, day 19: making progress visible

Today's objective: use each Scrum artifact and its commitment to answer a different question about direction, current work, or completion.

Read alongside: Scrum Artifacts in the Scrum Guide and Scrum: A Pocket Guide, fourth edition, §3.1, “Visualizing progress.” Allow roughly five minutes for this companion, plus the assigned reading.

Ask what the green card actually means

During the fictional ShiftSwap Sprint, a card labeled “decline explanation” moves into a column called Complete. The interface implementation is finished, but integrated checks with older records have not yet run.

The Developer who moved the card means that the interface task is complete. Elena interprets it as a usable product improvement. The sponsor sees a screenshot of the board and assumes the pilot can begin.

All three people can see the same card. They are acting on different meanings. Adding more color or another progress percentage will not resolve that ambiguity unless the underlying state becomes understandable.

Scrum's artifacts represent different information about work and value. Their associated commitments help people inspect that information against a meaningful reference. Start with the question you need to answer, rather than assuming one board column can answer everything.

Use the Product Backlog to inspect direction

The Product Backlog is the evolving, ordered source of improvements to the product. Its commitment is the Product Goal.

For ShiftSwap, that goal concerns dependable exchanges at the first two cafés. The backlog contains possible steps toward it, along with other product work that must be considered. Its order should help explain the current product judgment, not merely the sequence in which requests arrived.

Suppose the first several items concern a cosmetic dashboard redesign while employees still cannot understand declined requests. The discrepancy invites a conversation. Perhaps there is important new information about the dashboard; perhaps the goal or backlog order no longer reflects the actual decision.

The artifact does not make that judgment automatically. It makes the direction inspectable. People can ask how the proposed work contributes to the goal and what evidence supports its current importance.

Use the Sprint Backlog to inspect the delivery plan

The Sprint Backlog contains the Sprint Goal, the selected Product Backlog items, and the Developers' plan for delivering the result. Its commitment is the Sprint Goal.

The interface card is one small part of that plan. If the goal requires a dependable decline explanation, the remaining integrated checks need to be visible too. The Developers can distinguish a completed implementation task from a product item that has not yet met the Definition of Done.

During the Daily Scrum, this distinction helps them decide what to do next. A board showing several finished tasks may coexist with a serious obstacle to achieving the goal. Inspecting only the number of closed cards could encourage starting more implementation work when the better next step is completing the checks.

The plan should change as the Developers learn. Keeping the original list untouched while the actual work moves into private messages would reduce transparency, even if the original board remained beautifully organized.

Use the Increment to inspect the usable result

An Increment is the usable product result that works with what came before. Its commitment is the Definition of Done, the shared description of the required quality state.

For the decline flow, an implementation task being complete does not establish that this state has been reached. The integrated behavior must satisfy the applicable quality measures. When it does, the team can inspect a real product capability rather than infer it from activity records.

The Definition of Done also makes conversations about completion less dependent on private expectations. If one person assumes access checks are included and another treats them as later work, they do not yet share the same understanding of Done.

The Scrum Team needs an appropriate common standard, respecting any organizational minimum. The Developers adhere to it as they create the Increment. A convenient deadline or an enthusiastic stakeholder does not make an exception invisible.

Separate a shared quality standard from one item's behavior

For a particular decline item, the team might agree that the employee sees a readable reason and the next permitted action. Those examples describe what this item is intended to do.

The Definition of Done describes the common quality boundary applied to the Increment. In this fictional product, that might include integrated verification, appropriate access behavior, and operational checks. The actual standard must fit the product; this list is only illustrative.

Item-specific acceptance criteria can help clarify behavior, but they do not replace the shared standard. A screen could satisfy a narrow example while still failing an important integration check. Conversely, a technically dependable change might implement the wrong behavior if the team never clarified the user's need.

Elena's involvement helps the team understand value and expected behavior. Her personal approval is not the universal mechanism that turns every item into Done work.

Make the three questions explicit

When the sponsor asks whether the team is making progress, the answer can draw on all three artifacts:

These answers can differ without contradiction. The team may have a sensible direction and an unfinished Sprint item. It may have a Done Increment while still needing evidence that users benefit. Honest reporting preserves those distinctions.

Audit one progress claim

Choose a statement such as “we are nearly done” or “the Sprint is on track.” Identify the artifact and reference that would make it meaningful. Ask what is actually observable and which important uncertainty the statement leaves out.

Rewrite it with a concrete state, the remaining work or uncertainty, and the next decision it supports. You do not need a more complicated reporting tool to make one claim more useful.

Reflection: could two people looking at your progress report reasonably reach different conclusions about what is usable? Find the word or status that needs a shared meaning.

The next companion examines how to choose the supporting practices that make these conversations easier without mistaking every familiar technique for a Scrum requirement.