Quarterly Planning: Reset the Commitment System
Use quarterly planning to reconcile evidence, capacity, dependencies, and obligations—then replace stale commitments with an executable decision record.
Piotr Ciechowicz
Product manager · developer
Updated July 13, 2026
On this page14 sections
- 01Treat the quarter as a reset, not a planning horizon
- 02Close the old baseline before opening a new one
- 03Build an evidence delta, not a retrospective show
- 04Reconstruct capacity from claims already on it
- 05Reconcile dependencies as decisions
- 06Choose a coherent commitment set
- 07Write commitment envelopes, not feature promises
- 08Use progressive detail without turning the quarter into sprints
- 09Publish the baseline and its reopening rules
- 10Replace calendar reviews with trigger discipline
- 11A fictional quarterly reset
- 12The baseline test
- 13Sources
- 14Read next
The previous quarter does not end cleanly when the calendar says it does.
Unfinished work keeps its teams. Customer promises keep their dates. Operational demand keeps consuming specialists. Evidence has weakened some bets, while new requests arrive as though all capacity has returned to zero.
Quarterly planning fails when it adds a fresh layer of ambition without settling that inheritance.
Its job is not to predict the next twelve weeks. It resets the organisation’s commitment system.
That means reconciling change, releasing invalid promises, exposing capacity, closing dependency decisions, and authorising the next bounded set of work.
The quarter is only a convenient decision boundary. The useful output is a new baseline that people can execute and legitimately reopen.
Treat the quarter as a reset, not a planning horizon
General product planning runs continuously. It maintains the relationship between outcomes, evidence, obligations, capacity, dependencies, and change.
Quarterly planning is narrower. It is a periodic moment when several plans and commitments are reconciled together because local adjustments are no longer enough.
The reset should answer:
- Which previous commitments still deserve capacity?
- Which have been completed, invalidated, superseded, or stopped?
- What evidence or strategic context changed?
- What operating load and obligations enter the period before new bets?
- Which shared dependencies make the proposed set impossible?
- Who can accept the resulting trade-offs?
Do not use the session to rediscover strategy, rank an entire backlog, design a roadmap, or estimate delivery tasks. Those decisions may feed the reset, but they have different owners and evidence.
The broader product-planning system explains how to maintain the contract after the quarterly boundary has passed.
Close the old baseline before opening a new one
Start with the previous decision record, not a blank template. Every committed item needs a disposition.
Use states that preserve what actually happened:
- Completed: the promised decision, capability, or obligation reached its stated boundary.
- Continuing: the commitment remains valid and its remaining cost enters the new capacity view.
- Reshaped: the outcome remains, but evidence changed the approach, scope, or condition.
- Released: the evidence or strategy no longer justifies the commitment.
- Superseded: another decision now owns the need or obligation.
- Unresolved: the organisation lacks the evidence or authority to choose a disposition.
“Carried over” is too vague. It can hide unfinished execution, a decision nobody wants to revisit, or work that has become an obligation through repetition.
For continuing work, record the remaining decision, capacity, dependency, and promise. Sunk effort is not evidence that the next increment is worthwhile.
For released work, name the consequence. A commercial message may need correction, a contract may constrain stopping, and a partially built capability may create removal or operating work.
The reset is credible only when stopping work is treated as a managed decision rather than disappearance from a slide.
Build an evidence delta, not a retrospective show
A quarterly review can become a tour of launches and activity. The new baseline needs only evidence that changes a current choice.
For each strategic assumption behind active or proposed work, record:
- what the organisation believed at the previous baseline;
- what was observed during the period;
- what remains interpretation or unknown;
- which commitment the change affects;
- whether the evidence supports continuing, reshaping, stopping, or investigating.
A missed target is not a diagnosis. Neither is a successful release proof that the underlying mechanism worked.
Separate product evidence from execution evidence. A team may deliver as planned while the customer mechanism fails. It may miss a delivery forecast while new evidence makes the underlying bet stronger.
The 2020 Scrum Guide makes inspection useful only when it leads to adaptation, and expects adjustment when work or process moves outside acceptable limits.[1]
That statement belongs to Scrum’s iterative framework, not quarterly portfolio governance. The narrow transfer is sound: review without a changed decision is ceremony.
Reconstruct capacity from claims already on it
Do not begin with headcount multiplied by working days. Begin with the product system’s existing claims on scarce capability.
Include:
- continuing commitments and work needed to stop safely;
- production, support, incident, maintenance, and compliance demand;
- fixed obligations and accepted customer promises;
- planned absence, team changes, and specialist bottlenecks;
- cross-team work already promised elsewhere;
- quality boundaries that scope pressure cannot remove.
Use recent evidence and ranges where demand varies. Do not reserve a universal percentage for interrupts or innovation.
A fixed buffer can understate a volatile service and waste capacity in a stable one. The appropriate protection depends on observed demand, consequence, and response policy.
Show capacity by scarce capability, not only team. Three initiatives may fit three nominal teams and still depend on the same data engineer, legal reviewer, or migration window.
When the range cannot support all proposed commitments, reduce the commitment set or shorten the next decision. Do not solve uncertainty by silently assigning the same capacity twice.
Reconcile dependencies as decisions
A dependency line on a roadmap does not prove that another team has accepted the work, date, or trade-off.
For each load-bearing dependency, capture:
- the condition required and latest useful date;
- the external owner and evidence of agreement;
- capacity or authority the dependency consumes;
- the consequence if it does not resolve;
- a fallback controlled by the team;
- the person authorised to escalate or change the commitment.
Separate delivery dependencies from decision dependencies. Waiting for an API and waiting for a risk owner to interpret a control require different action.
GOV.UK agile governance guidance calls for explicit local decision authority, clear limits, and a named accountable route for choices beyond those limits.[2]
This is UK public-service guidance, not evidence for a commercial quarterly process. Its useful boundary is governance: a calendar cannot resolve an unnamed decision right.
If a dependency remains unaccepted at the baseline date, the affected work is conditional. Presenting it as committed transfers uncertainty to the delivery teams without transferring authority.
Choose a coherent commitment set
Prioritisation asks which options deserve investment. Quarterly planning asks whether the selected options can coexist with obligations, operational work, and shared constraints during this period.
Use the existing prioritisation decision; do not rerun scoring to make the available capacity look larger.
Test the proposed set as a system:
- Does every commitment serve a current outcome or named obligation?
- Is its next useful increment clear?
- Can the scarce capabilities support all items together?
- Are critical dependencies accepted or visibly conditional?
- Which work is displaced by this set?
- Which evidence would stop or reshape each bet?
- What operating burden could the set create?
Portfolio optimisation may change the balance across products or investment classes. Roadmapping may change the sequence of bets. The quarterly reset consumes those choices and makes their near-term consequences explicit.
Do not impose a universal number of priorities. A coherent set depends on coupling, scale, operating load, and available capability—not the aesthetics of a slide.
Write commitment envelopes, not feature promises
Each accepted item needs a boundary strong enough to coordinate work without pretending the solution is known.
A commitment envelope contains:
- intended outcome or obligation;
- population, product area, and excluded scope;
- capacity or capability currently allocated;
- fixed quality, legal, contractual, or risk boundaries;
- load-bearing dependencies and their state;
- decisive uncertainty and next evidence;
- decision owner and team authority;
- stop, reshape, and escalation triggers;
- external promise, if one has genuinely been accepted.
This is an editorial model, not a named industry standard.
“Deliver the analytics redesign this quarter” hides the outcome, solution uncertainty, and dependency risk. “Reduce investigation time for support analysts, beginning with the event model, subject to data-access concurrence” exposes them.
A commitment envelope is not permission to avoid accountability. It makes the accountable part precise: capacity, boundary, next decision, and consequence.
Use progressive detail without turning the quarter into sprints
GOV.UK planning guidance advises changing plans as teams learn, keeping distant work high-level, and adding detail to work that is near.[3]
Its context is UK government service delivery. It does not validate a quarterly cadence or prescribe this reset.
The transfer is about timing of detail. Near-term obligations and dependency decisions need operational clarity. Later work needs enough definition to reserve capacity and expose risk, not a task plan.
Do not plan every sprint during the quarterly reset. The people doing the work need authority to sequence and adapt inside the accepted envelope.
Do not replace false task certainty with vague “outcomes.” If no one can state the next decision, capacity claim, boundary, or evidence, the item is not ready for commitment.
Publish the baseline and its reopening rules
The final record should show the delta from the previous baseline, not only the new story.
Include:
- disposition of every previous commitment;
- evidence and strategic changes that mattered;
- capacity basis and protected operating work;
- accepted commitments and work explicitly not funded;
- unresolved dependencies and conditional items;
- owners, authority, and affected promises;
- review triggers and the route for admitting new work.
Make the record visible to teams that execute or absorb its consequences. Visibility does not mean every audience needs the same level of detail.
After publication, changes should create a delta record: new evidence or obligation, decision owner, work added or released, capacity displaced, and promise affected.
The quarter should not become a lock. It should make the price and authority of change visible.
Replace calendar reviews with trigger discipline
A quarterly baseline does not justify waiting three months to correct it.
Reopen a commitment when:
- its governing assumption fails;
- operational demand moves outside the capacity basis;
- a dependency misses its latest useful decision date;
- a new obligation crosses the agreed admission threshold;
- a protected quality or risk boundary is threatened;
- strategy changes the outcome or population in scope.
Ordinary requests enter the next appropriate decision point. Seniority does not make a request an emergency.
Team alignment remains a different job. It gives people a shared frame for coherent local decisions inside the baseline. Quarterly planning decides which commitments and boundaries that frame must now contain.
A fictional quarterly reset
Consider an explicitly fictional B2B service with a payments team and a reporting team. No result is claimed.
The previous baseline contained a billing migration, a reporting bet, and an onboarding experiment. The migration is incomplete. Incident demand has absorbed a specialist shared by both teams.
New evidence weakens the onboarding mechanism but not the activation outcome. A contractual export obligation also enters the next period.
The reset does not add all four items to a new roadmap. It first dispositions the old work.
The migration continues as an obligation with its remaining capacity exposed. The onboarding solution is released, while a smaller evidence decision preserves the outcome.
The export requirement is verified against the contract and given a latest useful date. Reporting work becomes conditional because its data dependency has no accepted owner.
The new baseline records the specialist constraint, displaced work, conditional dependency, authority for the export decision, and triggers that would reopen the capacity allocation.
The example stops before execution. It shows how inherited work, new evidence, and an obligation become one coherent commitment decision rather than four competing presentations.
The baseline test
At the end of quarterly planning, a specialist should be able to answer:
- What changed since the previous baseline?
- Which old commitments still consume capacity, and why?
- What work was released or displaced?
- Which scarce capability or dependency constrains the set?
- What is truly committed, conditional, or still an option?
- Who can change the baseline, and on which evidence?
If those answers are missing, the organisation has produced priorities without reconciliation.
Quarterly planning is valuable when it interrupts institutional momentum. It forces old promises to compete with current evidence and makes new ambition pay the full cost of capacity, dependencies, and obligations.
The point is not to make the quarter predictable. It is to make the next commitment honest.
Sources
- The 2020 Scrum Guide — Scrum Guides (Scrum-specific guidance on transparency, inspection, and adaptation; not quarterly portfolio guidance)
- Governance principles for agile service delivery — GOV.UK Service Manual (UK public-service guidance on authority boundaries and timely decisions)
- Planning in agile — GOV.UK Service Manual (UK public-service guidance on progressive planning detail and visible dependencies)
Read next
Related books
Two books to
read next.
If you want to go further on this topic, these are two good places to start.
01
leadership
The Five Dysfunctions of a Team
by Patrick Lencioni
A leadership fable about behaviours that damage teams and a practical model for rebuilding trust, conflict, commitment, accountability, and results.
02
leadership
An Elegant Puzzle
by Will Larson
A human-centric guide to solving complex problems in engineering management, from sizing teams to handling technical debt to managing organizational growth.
Some outbound links are affiliate links and support independent bookstores.