Scrum, day 04: planning under uncertainty

Today's objective: identify a decision worth making now, a decision worth delaying, and the evidence that would change your plan.

Read alongside: Scrum: A Pocket Guide, fourth edition, §1.5, “Agility can’t be planned.” Allow roughly five minutes for this companion, plus your book reading. The reading roadmap lists the editions and sequence.

Put a useful plan beside an uncertain future

The fictional ShiftSwap team has built the small invitation and approval flow from day 03. A sponsor now wants a date for introducing it at five cafés. The team has experience with one location, where a single manager approves exchanges. It has not yet investigated how the other four locations handle approval.

One proposal is to map every screen and integration for the five-café rollout, estimate each task, and add the numbers. Another is to avoid discussing dates until the team knows everything. Neither proposal gives the sponsor much help with the decision she actually faces: when to involve the other managers and what she can reasonably tell them.

A useful plan can contain a direction, a next step, assumptions, and a point at which the team will reconsider. Its usefulness depends partly on whether people can distinguish those elements. A date supported by a condition should travel with that condition whenever it is communicated.

Separate decisions by when they matter

The team lists several choices that the rollout appears to require. It asks what happens if each choice remains open for another week.

The table is an optional planning aid. It makes the team's reasoning discussable without pretending every decision deserves the same amount of analysis.

Waiting is useful when it preserves a choice and better information is likely to arrive. Waiting can also be expensive. The policy conversation needs to happen early enough for its answer to influence the work. Delaying it until the interface is finished would merely move the uncertainty to a more inconvenient moment.

Make the nearest work more concrete

The team can describe the next few days more clearly than the entire rollout. It will walk through recent swaps with the second café's manager, check the approval rules against the existing product, and identify the smallest complete flow that location could use.

For the later cafés, it records questions and likely differences. It does not create detailed screen specifications for policies that no one has checked. Those questions still belong in the plan: they tell the sponsor what the team needs to learn before increasing its confidence.

Suppose the sponsor needs an answer for a meeting on Thursday. The team can commit to providing an updated forecast on Wednesday, after the policy conversation. That is a concrete commitment to an action within its influence. It should avoid turning that commitment into an unsupported promise that all five cafés will be using the product the following week.

The important distinction is visible in the language: “We will inspect these two uncertainties by Wednesday” describes an intended action; “We currently expect the second café to need a small extension” describes a forecast. Both are useful when their meaning is clear.

Plan a response to new information

At the second café, the manager explains that another supervisor approves swaps during evening shifts. Sometimes both are working from older versions of the schedule. That changes the problem. Clear labels alone will not resolve conflicting approvals.

The Developers investigate how competing actions behave. They find a case where two approvals can overwrite each other. The team now has a reason to strengthen the approval flow before expanding the pilot. The earlier assumption that the second café needed only different wording is no longer credible.

It records the change where the sponsor can see it: the observation, its consequence, the proposed adjustment, and the next forecast review. Someone reading the plan later should be able to understand why the date moved. Otherwise, useful learning can look like arbitrary indecision.

In Scrum, adaptation has boundaries. The Sprint guidance from Scrum.org explains that the Sprint Goal must be protected and quality maintained, while scope can be discussed with the Product Owner as understanding grows. The discovery therefore calls for a conversation about the current goal and work; it does not give any participant permission to replace the Sprint's purpose casually.

Give a forecast an expiration condition

The team could communicate its revised position this way:

We expect to invite the second café after resolving concurrent approvals and checking the complete flow with its manager. That assumes its approval policy has no further exceptions. We will update the forecast after those checks, before promising dates to the remaining cafés.

This message gives the sponsor something to act on. She can schedule the necessary conversation, avoid announcing an unsupported rollout date, and ask whether the remaining uncertainty is worth the expected benefit.

The message is also open to challenge. Perhaps another café has a simpler policy and would make a better next pilot. A transparent assumption gives people a useful place to contribute.

Write a plan you can revise

Choose one change you are considering. Write a short note containing the desired result, the next concrete action, the most consequential assumption, and when you will inspect that assumption. Add one decision you can safely leave open and explain the cost of delaying it.

Now imagine that your assumption turns out to be false. Write the message you would send to someone relying on the plan. Include what remains valid, what must change, and when they can expect a better forecast.

Reflection: which sentence in your current plan sounds more certain than the evidence allows? Rewrite it so someone else could make a sensible decision from it.

In the next companion, the team follows a small change through its actual waiting time and discovers why busy people can still deliver slowly.