~/vladvisinescu_
<- cd ~/tutorials

tutorial

Scrum, day 37: planning across different horizons

Today's objective: distinguish a longer-term direction, a near-term forecast, and today's delivery plan, then explain how new evidence should affect each.

Read alongside: Mastering Professional Scrum, chapter 5, focusing on a product mindset and alignment. Allow roughly five minutes for this companion, plus the book reading.

One question hides several planning needs

A café owner asks the fictional ShiftSwap team what it will deliver over the next three months. They want to prepare supervisors, coordinate a possible expansion, and understand whether further investment makes sense.

The team could respond with a detailed feature calendar. That would appear helpful while concealing uncertainty about user needs and the work required. It could also refuse to discuss the future because Scrum involves adaptation. That would leave legitimate coordination needs unanswered.

A useful response separates the decisions the owner needs to make from the level of detail the team can currently support. Different horizons need different kinds of planning information.

Keep the direction clear

ShiftSwap's current direction concerns reliable exchanges at the first two cafés. That focus helps the team evaluate requests, select useful experiments, and explain why some attractive features are deferred.

The direction can be described without pretending to know every implementation step. The team may expect to improve request clarity, manager handover, and the relevance of alerts. Which specific changes prove useful will depend on what it learns.

A longer-term plan can therefore communicate intended outcomes, major uncertainties, and important decision points. It should make clear which elements are current intentions and which are external constraints. Those distinctions help stakeholders use the plan without treating every possibility as a promise.

Make the near term more concrete

For the next Sprint, the team needs enough understanding to form a coherent goal and a credible forecast of work. It examines likely items more closely, discusses examples, and identifies dependencies that could prevent completion.

This additional detail is justified because decisions are approaching. Refining a notification change likely to be selected soon may reveal a missing responsibility rule. Elaborating an export feature that might matter in six months may provide little immediate value and could become obsolete before implementation.

The distinction is a matter of judgment, not a fixed number of Sprints that every team must refine. The team should invest enough in upcoming work to support useful decisions while avoiding unnecessary precision about distant possibilities.

Let today's plan respond to discoveries

During the Sprint, the Developers organize the actual work and adapt it as they learn. An unexpected request-state case may require pairing, a scope discussion with Elena, or a different implementation sequence.

These daily adjustments should remain connected to the Sprint Goal. They do not require rewriting the product's broad direction every time a task changes. Conversely, a new fact that undermines the expected user benefit may need a broader product discussion.

The useful question is which planning assumption the observation challenges. A local implementation surprise, a newly understood user need, and a change in the organization's priorities have different implications.

Show assumptions alongside a forecast

The café owner wants to prepare a third location. Elena can explain that expansion depends on evidence from the current pilot and on understanding differences in staffing policy. The Developers can explain what they know about the work and which dependencies remain uncertain.

Instead of presenting an unconditional date, the team can describe a current forecast with its scope and assumptions, then agree when to revisit it. The owner can use that information to delay irreversible preparations or choose a smaller initial commitment.

This is useful planning even when uncertainty remains. Its purpose is to support a decision under current knowledge, not to make uncertainty disappear through confident wording.

Avoid turning the roadmap into a hidden contract

Suppose a slide lists automatic alerts in November and a multi-café dashboard in December. Stakeholders may naturally organize around those dates, even if the team privately considers them tentative.

Labels alone may not solve the problem. Elena should discuss how the roadmap will change, what evidence could change it, and which decisions stakeholders plan to make from it. The team can use explicit review points and distinguish committed external obligations from evolving product intentions.

When the plan changes, explain the new evidence and its consequence. Replacing dates silently weakens trust. Defending an outdated feature merely because it appeared on a slide can waste the opportunity to build something more useful.

Connect planning conversations instead of multiplying them

The team does not need a separate recurring meeting for every horizon. Product discussions, refinement, Sprint Planning, daily adaptation, and stakeholder inspection can provide the necessary information when used coherently.

For example, a Review observation may change Elena's ordering of upcoming work. Refinement may reveal that the newly important item needs an investigation. Sprint Planning can then select a meaningful result that reflects that uncertainty. The daily plan organizes the work toward it.

The connection matters more than the number of documents. A detailed roadmap and a well-maintained board can still contradict each other if nobody explains how new information travels between them.

Prepare a three-horizon explanation

Choose a product decision you need to discuss. Write its longer-term purpose, the next useful result you can reasonably pursue, and the immediate work needed to move toward that result.

For each horizon, identify one assumption and one observation that would cause an adjustment. Name who needs to participate in that adjustment and who needs to hear about it. Then remove details that imply more certainty than you currently have.

Reflection: which part of your plan is detailed because a decision is approaching, and which part is detailed mainly because uncertainty feels uncomfortable?

Next, day 38 examines how refinement prepares upcoming decisions.

  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