Scrum, day 28: keeping a Sprint coherent

Today's objective: use a Sprint Goal to choose a scope adjustment that preserves a coherent result when new information changes the delivery plan.

Read alongside: Mastering Professional Scrum, chapter 3, focusing on Sprint Goals, and the Scrum Guide's Sprint Goal commitment. Allow roughly five minutes for this companion, plus the book section.

Give the Sprint a result worth protecting

In a later Sprint, the fictional ShiftSwap team chooses this goal: a manager taking over the evening shift can reliably identify pending swap decisions and act on their current state.

The Developers select work for a pending-request view, clear handling of outdated approval attempts, and a shortcut for filtering requests by the incoming supervisor. They also plan the integration and verification needed for a usable result.

The goal connects these choices. It explains why an attractive list of requests is insufficient if the manager can act on stale information. It also creates room to adjust the convenience features when the team discovers more about the essential behavior.

Notice when a list disguises several directions

Compare the proposed goal with “finish the pending list, filtering, notifications, and account preferences.” That sentence names work but does not explain the useful result connecting it. If time becomes tight, the team has little basis for deciding which trade-off preserves the purpose of the Sprint.

The handover goal provides a clearer question: after this Sprint, can the incoming manager make the relevant decisions without reconstructing the previous supervisor's conversations?

The team still needs concrete examples and a credible plan. A goal is not a substitute for understanding the work. It gives that understanding a direction so that the plan can evolve without dissolving into unrelated activity.

Encounter information that changes the forecast

Halfway through the Sprint, the Developers discover that old requests do not consistently identify the supervisor expected to handle them. The proposed automatic filter would require more investigation and data work than anticipated.

At the same time, a café manager clarifies that being able to see the full pending list and narrow it manually would already remove much of the handover confusion. The automatic filter was a convenience assumption, not the underlying user need.

This discovery does not guarantee that a simpler approach is sufficient. It gives the team a plausible alternative to examine with Elena. They need to check that a manager can still find and act on relevant requests without introducing new ambiguity.

Compare options by what remains usable

The team considers three responses. It could keep every selected feature and postpone verification. It could defer the automatic filter and finish the dependable pending-request flow. Or it could complete the filter while leaving outdated approval handling for a later Sprint.

The first option weakens confidence in the product. The third emphasizes a convenience feature while leaving the core decision unreliable. The second appears consistent with the goal if the simpler list remains understandable and manageable for the two cafés.

That condition matters. If the full list were so large that a manager could not find the relevant decisions, removing the filter might undermine the goal. The team must evaluate the actual setting rather than assume that any reduction in scope is acceptable.

Negotiate the work without quietly rewriting the purpose

The Developers explain the discovery, the remaining work, and the proposed simpler flow. Elena helps evaluate the user consequence and discusses the relevant example with a manager. Together, they negotiate the scope adjustment and make the updated plan visible.

The Sprint Goal remains the same. The automatic supervisor filter returns to the Product Backlog for consideration against other needs. The team records why it was deferred so that it does not silently become a promise for the next Sprint.

The current Scrum Guide gives the Sprint Goal this focusing role while allowing the exact work to change. It also protects quality during the Sprint. A scope adjustment should preserve an honest usable result, rather than merely keep the board looking successful.

Give each accountability useful information

Elena needs to understand what the adjustment means for the managers and the Product Goal. She does not need to assign each implementation task. The Developers need to understand the product consequence so that they can choose a technically coherent plan.

Radu may help the discussion if people are treating the original list as an unchangeable contract. He can ask what the Sprint was meant to achieve and what evidence now challenges the plan. He does not need to choose the product trade-off on the team's behalf.

A stakeholder who expected the filter should hear about the change promptly. Showing them the revised usable flow and explaining the reason supports a more productive conversation than waiting until the Review to reveal a surprise omission.

Handle an endangered goal honestly

Suppose further investigation shows that reliable approval requires more work than can be completed in the remaining time. The Developers should make the risk visible immediately and examine the available options with Elena. They should not rewrite the goal afterward to match whichever tasks happened to finish.

A forecast can prove wrong even when people act responsibly. The team can inspect how the uncertainty arose, what remains useful, and what to change next. That learning depends on preserving the distinction between the intended result and the actual outcome.

If circumstances make the goal obsolete, cancellation is a separate Product Owner decision under the Scrum framework. Difficulty alone does not establish obsolescence. The team needs to explain what changed in the purpose, not merely that completing the work became inconvenient.

Practice a scope conversation

Choose a Sprint Goal and three pieces of work intended to support it. Introduce a realistic discovery that makes one piece more expensive. Write two possible scope adjustments and explain the user-visible result of each.

Identify what you would need to verify before choosing. Keep the quality standard explicit. Then describe the conversation between the Developers and Product Owner, including what stakeholders should learn about the revised expectation.

Reflection: if you removed half the selected items, could you explain which useful result must still hold for the Sprint Goal to remain meaningful? If every item appears equally essential, the goal or the proposed slices may need further examination.

Next, day 29 looks for a smaller usable piece that can reach Done earlier.