Continuous Planning Playbook

This playbook introduces a continuous planning system for quarterly planning. The core shift: PI Planning stops being where the plan gets made and becomes where the plan gets published. The real planning happens throughout the quarter. Teams using the operating model will recognize the events described here as the rhythm layer; frames, roadmaps, and funnels are the artifacts that these events maintain.

Core Philosophy

PI Planning concentrates planning into an intensive, multi-day event. Even when well executed, this batch approach has structural limits: strategic context is compressed into opening presentations, dependencies surface under time pressure, and the plan becomes a snapshot that starts aging immediately.

Continuous planning distributes this work across the quarter. Teams maintain ongoing awareness of strategic context rather than absorbing it in a keynote. Dependencies get identified and negotiated as they emerge, not discovered in a planning room. Commitments evolve with new information rather than fighting against a plan made weeks ago.

The PI event still exists, but its purpose shifts. It becomes an alignment moment; finalizing agreements that have been in development, strengthening relationships across teams, and committing to a plan that has already been substantially shaped. Less theater, more ratification.

Engineering adopted continuous deployment. Product and UX moved to continuous discovery. Planning is the remaining batch process in an otherwise flow-oriented system. That discontinuity creates friction: insights from discovery wait for the next planning cycle, deployment capabilities sit unused while teams wait for plan boundaries, and the organization oscillates between “planning mode” and “execution mode” rather than maintaining a steady flow of value and feedback.

Continuous planning closes this gap. Strategic alignment becomes ongoing rather than periodic. Feedback reshapes the plan when it arrives, not quarters later. The work of planning; understanding context, surfacing dependencies, making commitments; becomes a practice rather than an event.

The Continuous Planning Timeline

The continuous planning calendar spans 12 weeks centered on the PI event. It establishes a rhythm that builds toward a well-prepared PI event and sustains momentum for execution and adaptation throughout the quarter.

Activities occur across all layers of the organization: Portfolio, Group, and Team. While specific events appear as discrete points on the timeline, the activities that support them continue throughout the quarter.

The PI event marks a period of intense focus and the forum for the final responsible moment to make decisions based on current information.

Pre-PI Activities (T-6 to T-2 Weeks)

The evolution of PI Planning has shown that cross-team communication remains central to its value, but many of the activities associated with the event can be distributed over a larger preparation window.

The pre-PI phase is where most of the planning work happens. There is a natural momentum that builds as organizational strategy coalesces into a clear direction, cascades into alignment across portfolio initiatives, and culminates in a preliminary execution plan.

T-6 Weeks: Strategic Theme Setting, Technical Investment Review

Halfway through the quarter, progress becomes measurable. Are metrics moving in the right direction? Have you centered on the right outcomes? Increased confidence leads to strategic refinement and advances in each layer of the organization.

Portfolio Layer

• Portfolio leads work with executive leadership to understand strategic pillars and high-level outcomes for the upcoming quarter
• Platform portfolios identify services and capabilities they intend to deliver (or deprecate) based on the capabilities required by strategic pillars
• Technical leads and architects outline the architectural runway or technical discovery necessary for upcoming initiatives

Group Layer

• Technical investment review (ROI analysis, technical debt prioritization)
• Groups and teams align on cross-team initiatives that may span the quarter

Team Layer

• Begin clearing technical debt for known upcoming “Next” roadmap items

T-4 Weeks: Outcome & Metrics Refinement, Dependency Negotiation

Once strategic direction is established, individual portfolios and platforms create aligned business, technical, and partner goals. Teams align their goals to the portfolio. These goals are outcome-based, with a metric and impact, documented in portfolio and team-level frames. The goal is to gain confidence that the outcomes are viable for implementing the strategy.

Portfolio Layer

• Review and lock strategic themes and high-level outcomes
• Set success metrics for high-level outcomes (directional measures, targets)
• Identify coarse-grain cross-portfolio dependencies and risks
• Begin dependency negotiation with other portfolios

Group Layer

• Map high-level outcomes to portfolio-level and team-level outcomes
• Break down outcomes into epics, features, journeys, or experiments
• Align with other groups on shared initiatives
• Draft collaboration agreements

Team Layer

• Project that current PI work will complete
• Discuss prioritization of remaining undone work in context of strategy changes
• Continue technical debt clearance
• Begin coarse-grained sizing of upcoming “Next” epics

T-2 Weeks: Backlog Refinement, Cross-Portfolio Dependency Review

As outcomes develop, business units might discover dependencies with portfolios and platforms. As teams refine their epics, they will begin to have more detail about the timing and scale of dependencies, and a rough schedule for the first few sprints.

Portfolio Layer

• Continue to receive feedback from teams regarding outcome viability
• Plan coordination of releases for cross-portfolio dependencies

Group Layer

• Teams identify cross-team dependencies
• Teams document their “Related Frames” links
• Groups and teams plan their coordination sessions for the PI Event

Team Layer

• Teams conduct high-level sequencing of “Next” epics
• Teams refine first epics to have an initial backlog of 2-3 sprints
• Teams plan interaction patterns for the development of dependent features

PI Event Activities (T-0, 3-Day Event)

PI Planning creates organization-wide, synchronized planning for an entire quarter. This “big room” approach shortens communication distances between teams, which is essential when multiple business units must coordinate to deliver products.

Traditionally, teams spent most of the multi-day event on deep refinement: estimating epics, assessing capacity, building schedules. Only then did they have enough context to identify cross-team dependencies and risks. The real coordination work got squeezed into whatever time remained.

The continuous planning evolution keeps cross-team communication central while distributing many traditional planning activities across a longer preparation timeline. When teams arrive having already absorbed strategic context, drafted outcome-centered roadmaps, and refined work enough to surface major dependencies, they can dedicate the event itself to what matters most: alignment, negotiation, relationship-building, and commitment.

Day 1: Context, Alignment, and Collaboration

The goal of the first day is for all teams to review their development for the quarter and raise any issues. Teams plan throughout the day, contacting leads, managers, or other teams as needed to resolve questions and refine plans.

Morning (All Hands)

Leadership provides the key context for the company’s goals for the upcoming quarter:

• Celebrating wins from the prior increment, including learnings and pivots
• Present the business context and strategic alignment
• Present the product vision
• Present the enterprise architecture changes required for the quarter

Each portion is intended to be interactive. The tradeoff is to keep the session brief and useful to all present without descending into minutiae.

The overview is followed by a discussion of changes to the process based on lessons learned from the last PI event. With context and process laid out, portfolios and teams move into breakouts.

Mid-Day (Breakouts)

Between the kickoff session and the plan review, teams focus on refinement and coordination. The goal is to effectively plan the schedule and capacity of the first 2-3 sprints:

• Map and split epics and stories to explore and divide work into valuable slices
• Plan a rough breakdown of the initial order of execution
• Hold conversations with product leads to resolve development questions
• Hold conversations with dependent teams
• Build an initial high-level release and dependency management plan
• Identify risks to schedule or coordination, and adjust timing or create contingency plans
• Set a goal for internal continuous improvement

Teams can set themselves up for success by coming prepared with a refined backlog, a list of leads and groups to talk to, and pre-scheduled appointments with key dependencies.

Patterns that reduce friction during breakouts:

1. Dedicate a breakout room for each team. Publish a list of all teams’ breakout session links so anyone can “drop in.”
2. Publish a loose schedule. Use “restaurant scheduling” where others reserve a time slot or join a pager list.
3. Free up portfolio leads. Developing strong facilitation skills within teams reduces dependence on leads and frees their time for cross-team conversations.
4. Favor whole team interactions over representation. Sending individuals out to dependency discussions is a false efficiency; it obscures the costs of recommunicating information and misses perspectives.

Afternoon (All Hands)

After the first round of breakouts, portfolios and teams will have initial assessments of capacity, scheduling, dependencies, and risks. The afternoon session provides a way to share progress and surface issues:

• Initial review of portfolio plans
• Teams present issues that have been resolved
• Raise any issues identified for further action

Day 2: Iteration (Optional)

When teams are distributed across multiple time zones, two days may be insufficient for the necessary cross-team communication. A third day provides additional interaction time.

• Morning: Roadmap presentation and feedback sessions
• Mid-Day: Resolving issues with teams’ plans and contacting others as necessary
• Afternoon: Iterative review and checkpoint of portfolio plans with more resolution of outstanding issues

Day 3: Commitment and Continuous Improvement

Morning (All Hands)

The morning opens with a planning status refresh. Teams surface remaining issues for breakouts. By this point, the easy problems have been solved; what’s left needs more focused attention. Activities include:

• Setting dependency management strategies and collaboration agreements
• Networking and relationship-building

Mid-Day (Breakouts)

• Team collaboration sessions
• High-level release and dependency management planning
• Continuous improvement goal setting for team-level outcomes

Afternoon (All Hands)

The final session summarizes portfolio and team efforts, including any de-committed items. This is followed by a confidence check to secure organizational commitment.

• Roadmap presentation and feedback sessions
• Confidence Vote and Commitment (fist-of-five; votes of 1-2 must explain concerns; target average of 3.5+)
• PI retrospective: decisions about changing PI going forward

Post-PI Activities (T+2 to T+6 Weeks)

The plan published at the PI event is a starting point, not a fixed contract. The post-PI phase focuses on execution, adaptation, and preparation for the next cycle.

T+4 Weeks: Mid-PI Check

Portfolio Layer

• Conduct mid-PI business review against objectives
• Portfolios conduct retrospective activities and gather data around PI efficacy

Team Layer

• Sprint retrospectives and frame check-ins continue

T+6 Weeks: The Cycle Begins Again

• Next PI preparation begins; T-6 becomes the new T+6
• Portfolio-level roadmap adjustments communicated

Plan Adaptation During Execution

The plan published at the PI event is a hypothesis, not a contract. Continuous planning assumes the plan will change. Experiments resolve. Software deployments are measured for efficacy and usage. Learnings happen that you will want to use to adjust your plan.

Moments when you may want to adjust:

• Experiment results: Hypothesis invalidated or validated with high confidence; continuing the current path would waste capacity
• Customer/market feedback: Pattern confirmed across multiple sources; strategic relevance validated by business lead
• Discovery insights: Technical or design finding materially changes scope, sequence, or feasibility
• Dependency changes: Committed dependency at risk or failed; contingency plan activation required
• Capacity changes: Sustained capacity shift (not single-sprint variation) affecting committed outcomes
• Missed requirements: Something forgotten when constructing the backlog or roadmap becomes apparent

Healthy adaptation means adjusting the plan, not abandoning it:

• Update artifacts. Changed outcomes are reflected in roadmaps, team frames, and PI objectives. If it’s not written down, it didn’t happen.
• Drive communications. Planning changes are communicated within the team, group, portfolio, and to the broader stakeholder community.
• Close loops. When an experiment drives a change, document the learning. When a dependency slips, update the contingency. Decisions have a rationale.
• Respect commitments. Changing a committed outcome requires explicit acknowledgment. “We’re no longer pursuing X because we learned Y” is healthy. Quietly dropping commitments is not.
• Preserve the rhythm. Weekly syncs, mid-PI reviews, and the planning calendar continue. Adaptation happens within the system, not around it.

Communicating Significant Adaptations at Mid-PI Review

The Mid-PI Business Review (T+4) is the formal checkpoint for plan health. Come prepared to discuss:

• Outcomes on track, at risk, or changed
• Key learnings from experiments and discovery
• Dependency status and any activated contingencies
• Proposed adjustments for the remainder of the PI
• Early signals relevant to next PI planning

Events Reference

Each event in the continuous planning system has a specific purpose, required participants, expected inputs and outputs, and success criteria.

Strategic Pillar Setting (T-6)

Purpose	Establish portfolio-level strategic direction and high-level outcomes for the quarter
Timing	T-6 weeks; 2-4 hours
Participants	Portfolio Product Lead, Portfolio Engineering Lead, Business Lead, Portfolio Manager, Executive Sponsors, Dependency Groups, Customer Support Ops & Enterprise Architecture
Inputs	Corporate strategy, prior quarter results, market intelligence, customer feedback, technical debt inventory
Outputs	Draft strategic themes (2-4), high-level outcomes with directional measures, investment allocation guidance
Success Criteria	Themes are clear, measurable, and actionable; executive alignment achieved; outcomes expressed as impacts, not features

Technical Investment Review (T-6)

Purpose	Prioritize technical outcomes, debt remediation, and platform capability investments based on business impact and projected ROI
Timing	T-6 weeks; 2-3 hours per group
Participants	Group Engineering Manager, Solution Architect, Group Product Manager, Team Engineering Managers
Inputs	Technical debt inventory, platform service catalog, adoption metrics, incident data, team capacity projections
Outputs	Prioritized technical investment backlog, platform adoption commitments (draft), capacity allocation for technical work
Success Criteria	Technical investments tied to business outcomes; clear ROI articulation; platform dependencies identified

Outcome Refinement (T-4)

Purpose	Develop portfolio and platform-level outcomes, metrics, and impacts aligned to business, product, and technical strategies
Timing	T-4 weeks; 2-3 hours per group
Participants	Teams, Product Leads, Engineering Leads, Managers
Inputs	Corporate strategic pillars
Outputs	Portfolio and platform-level outcomes with supporting metrics and impacts; updated portfolio and team frames
Success Criteria	Portfolio and platform frames updated with latest quarterly roadmaps

Dependency Negotiation (T-4)

Purpose	Discuss collaboration plans for managing cross-portfolio dependencies
Timing	T-4 weeks; 1 hour per dependency
Participants	Teams, Portfolio Product Leads, Portfolio Engineering Leads, Portfolio Managers
Inputs	Team and portfolio backlogs
Outputs	Backlog updated with dependencies; “Related” links in portfolio and team frames
Success Criteria	Portfolios have initial commitment for identified dependencies; plan for closing unresolved dependencies before PI event

Cross-Portfolio Dependency Review (T-2)

Purpose	Identify and negotiate dependencies between business portfolios and platform portfolios
Timing	T-2 weeks; 1-2 hours
Participants	Portfolio Managers from all portfolios, Release Managers, Portfolio Product Leads (as needed)
Inputs	Draft portfolio roadmaps, platform service roadmaps, known dependency requests, adoption agreement drafts
Outputs	Related frames (cross-portfolio), draft adoption agreements, risk management plans, escalation items for PI event
Success Criteria	All cross-portfolio dependencies identified; owners assigned; preliminary commitments documented; blockers escalated

Iterative Backlog Refinement (T-2)

Purpose	Break down large backlog epics and stories into deliverable size; sequence scope in prioritized order
Timing	T-2 weeks; 2-3 hours per team
Participants	Teams, Product Leads, Engineering Leads, Release Managers
Inputs	Team and portfolio backlogs
Outputs	Smaller stories to implement initial backlog epics
Success Criteria	Well-formed backlog with 2-3 sprints of executable small stories sequenced

PI Event: Day 1

Business Context, Product Vision, and Strategic Alignment (All Hands)

Duration	60 minutes
Presenter	Business Lead, Product Lead; Executive sponsor introduction
Content	Celebrate prior wins, business performance, market context, strategic themes, key outcomes for the quarter

Team Collaboration Breakouts

Duration	3-4 hours (with breaks)
Participants	All team members; Product Leads, Engineering Leads, Architects, and Release Managers available as needed
Activities	Refine team-level outcomes, identify remaining dependencies, negotiate with dependent teams, update roadmap artifacts

Initial Plan Review (All Hands)

Duration	10-15 minute presentations per team/group; gallery walk alternative for larger groups
Participants	All team members; Product Managers and Engineering Managers facilitate
Activities	Teams outline progress and raise any new issues with schedule or capacity

PI Event: Day 2 (Optional)

Day 2 accommodates larger, more complex portfolios with more teams and dependencies requiring additional coordination:

• Additional time for team collaboration breakouts
• Extending the initial plan review

PI Event: Day 3

Risk Planning

Duration	30 minutes
Participants	All team members; Product Leads, Engineering Leads, Architects, and Release Managers available on demand
Activities	Teams present unresolved capacity, dependencies, schedules, and risks; set plans to address them via breakouts

Revised Plan Review

Duration	2-3 hours
Format	10-15 minute presentations per team/group; gallery walk alternative for larger groups
Feedback Focus	Outcome clarity, dependency risks, alignment with strategic themes, capacity concerns

Confidence Vote and Commitment

Duration	30-45 minutes
Method	Fist-of-five vote (1-5 fingers); votes of 1-2 must explain concerns; address blockers before re-voting
Target	Average confidence of 3.5+ across all teams; no unresolved 1-2 votes

Recurring Events

Weekly PM Sync: Product Managers meet weekly to manage scope, adjust priorities, and refine features for the current and next PI.

• Attendees: Group PMs, Product Managers, Release Managers
• Duration: 60 minutes weekly

Weekly Engineering Sync: Engineering Managers meet to identify risks, track dependencies, and address impediments across teams.

• Attendees: Engineering Managers, Release Managers
• Duration: 30-60 minutes, often twice weekly

Weekly Architect Sync: Solution and Enterprise Architects meet to ensure technical alignment, manage architectural runway, and coordinate enabler work.

• Attendees: Enterprise Architect, Solution Architects, Technical Leads
• Duration: 60 minutes weekly

Mid-PI Business Objective Review (T+4)

Purpose	Adjust business outcomes and plans using metrics and progress from the first half of the quarter
Timing	T+4; 2-3 hours
Participants	Portfolio leadership, Business Leads, executive sponsors
Inputs	Progress against PI objectives, business outcome assessment
Outputs	Portfolio review; identified adjustments needed
Success Criteria	Plans for remaining development reflect the reality of current progress

Supporting Artifacts

Continuous planning produces and maintains several artifacts that make planning visible, durable, and actionable.

Outcome-Centered Roadmap

Purpose: Communicate strategic intent and planned outcomes without locking in specific features or timelines.

Structure:

• Now (current PI): Committed outcomes with associated epics, features, and experiments
• Next (PI+1): High-confidence outcomes with preliminary scope
• Later (PI+2 and beyond): Directional outcomes, subject to change

Owner: Product Lead (portfolio level), Group Product Manager (group level), Product Manager (team level)

Lifecycle:

• Created/updated during Strategic Theme Setting (T-6 weeks)
• Refined during Outcome Refinement (T-4 weeks)
• Finalized at PI event
• Continuously updated during execution; formally reviewed at Mid-PI

See Outcome-Based Roadmap for the template and Roadmapping for the practice.

Frames

• Outcomes & Metrics for Goals (Product & Technical Outcomes, Process Improvement)
• Related Frames for Dependencies

Product Backlog

• Definition-of-Ready, Definition-of-Done
• Vertical slices of value
• Technical investment options are stored in the product backlog

Dependency Management

Modern software systems incorporate numerous frameworks, infrastructure, and specialized tools; no one team can maintain it all. With multiple business and platform portfolios, dependency management is critical.

Types of Dependencies

Larger enterprises adopting a product model exhibit common dependency patterns:

• Business to Business: Business portfolios depend on each other for shared capabilities or data. (Example: one revenue channel depends on another for shared customer data services.)
• Business to Platform: Business portfolios depend on platform portfolios to deliver capabilities, infrastructure, or services. (Example: a business portfolio needs the infrastructure portfolio to provision new environments.)
• Platform to Business: Platform portfolios depend on business portfolios to adopt their offerings. (Example: the infrastructure team needs business portfolios to migrate from end-of-life services.)
• Platform to Platform: Platform portfolios depend on each other for foundational services. (Example: developer experience depends on infrastructure for the underlying platform.)

Team Interaction Patterns

The methods teams choose to work together are influenced by domain knowledge, technical skills, size of effort, complexity of change, system ownership boundaries, and distance between teams. As each factor increases, more coordination is required.

Well-known patterns for building dependent work:

Collaboration: Two or more teams work closely together for a limited time to solve complex problems. High-bandwidth, iterative work often used for innovation, discovery, or critical dependencies. Temporarily reduces availability of both teams for adjacent work. Use when neither team has the skill set to deliver alone, or when delivery is time-critical.

X-as-a-Service: One team provides a well-defined capability that other teams consume through a stable interface. The providing team controls timing and implementation; the consuming team integrates via API, library, or platform feature. Use when there is a clear provider-consumer relationship with a stable interface, or when the providing team needs to manage their own roadmap independently.

Facilitation: One team helps another build capability rather than building it for them. The facilitating team shares knowledge, provides guidance on architecture or practices, and helps the receiving team become self-sufficient. Use when a team needs to build skills in a new domain, or when knowledge transfer produces more long-term value than direct delivery.

Identifying Dependencies

Dependencies surface through structured activities during the continuous planning cycle:

• T-6 (Strategic Theme Setting): Platform portfolios identify services and capabilities required by strategic pillars
• T-4 (Outcome Refinement): Groups map outcomes to cross-team initiatives; portfolios begin negotiation
• T-2 (Cross-Portfolio Dependency Review): All portfolio managers review cross-portfolio dependencies; owners assigned
• PI Event (Breakouts): Teams negotiate remaining dependencies face-to-face

Dependency Negotiation

When a dependency is identified, the involved teams negotiate:

• Scope: What exactly is needed? Is the full feature required, or can a subset unblock the work?
• Timing: When is the capability needed? Can sequencing reduce the dependency’s criticality?
• Interface: What does the handoff look like? API contract, shared code, knowledge transfer?
• Contingency: What happens if the dependency slips? What is the fallback plan?
• Interaction pattern: Collaboration, X-as-a-Service, or Facilitation? Which pattern fits this specific dependency?

Dependency Tracking During Execution

• “Related Frames” links connect dependent portfolio and team frames
• Weekly PM, Engineering, and Architect syncs surface dependency risks early
• Mid-PI Business Review formally assesses dependency health
• Teams update contingency plans as dependencies evolve

Reducing Dependency Friction

Long-term strategies for reducing the cost of cross-team coordination:

• Align team boundaries to value streams to minimize cross-team handoffs
• Invest in platform capabilities that provide self-service interfaces, reducing the need for synchronous coordination
• Build architectural runway so teams can extend capabilities without waiting for platform teams
• Strengthen facilitation skills within teams to reduce dependence on leads and managers
• Favor collaboration over handoffs when teams must work together; short-term expensive, long-term cheaper than coordination overhead

Resources

• Framing — the alignment framework whose events and artifacts this playbook operationalizes
• Continuous Planning — the concept behind this playbook
• Roadmapping — the practice of maintaining outcome-centered roadmaps
• Outcome-Based Roadmap — the Now/Next/Later roadmap template
• Dependency Management — strategies for coordinating work across team boundaries
• Continuous Everything — the broader shift from batch to continuous practices