Moving from PI Planning to Continuous Planning (CP)
How We Evolved Our Approach to Fit the Needs of a Fast-Moving AI Team
For the past 5 years, our teams followed a traditional PI (Program Increment) planning model. It gave us structure, helped us coordinate dependencies, and aligned cross-functional workstreams around shared milestones and priorities. But as our product focus evolved into more experimental and iterative AI capabilities—including generative AI—it became clear that our planning system needed to evolve, too.
This post captures the evolution from PI planning to Continuous Planning (CP)—why we made the change, how we did it, the lessons learned, and where we are now.
The Limitations of Traditional PI Planning for Iterative Use Cases
Traditional PI (Program Increment) planning works well for many teams, especially in more stable product environments or multi-year transformation initiatives with long-term roadmaps. But, as our team navigated the fast-paced and exploratory AI product space, we struggled to keep up with the rapid pace of change, iterating on MVPs based on customer feedback.
The standard process required epics to be documented and reviewed by a Capacity Planning Leadership Team roughly 10 weeks before planning began. Once approved, teams entered a detailed pre-planning phase—decomposing features, reviewing dependencies, and aligning across scrum teams.
While this structure helps drive long-term alignment, it became clear that our need to experiment, learn quickly, and adapt to new insights in real time wasn’t well-supported by the existing rhythm. We often found ourselves locked into a plan based on assumptions that had since shifted, which added stress and rework for the team.
Additionally, the global nature of our team made the 5-day PI planning sessions more challenging to execute effectively. With colleagues spread across multiple time zones, collaboration required extra effort, and fatigue was a common theme.
These challenges didn’t mean the PI process was broken—it simply meant we needed something different to support the kind of iteration, responsiveness, and autonomy our product space demanded.
Introducing Continuous Planning (CP)
To address these pain points and give our teams more flexibility, I introduced a Continuous Planning (CP) model. The intent was to preserve the best parts of PI planning (alignment, shared understanding) while reducing overhead and enabling faster iteration.
Here’s what changed:
We plan for fewer epics per cycle—typically 2 to 4, rather than 15.
Planning takes place in a single day, usually the last day of the sprint, rather than five consecutive days.
Each CP covers two sprints (approximately one month), allowing more focused, short-term delivery.
Pre-planning is shortened to 1 week, helping teams stay close to current priorities and customer needs.
Because we are a global team, our colleagues in India adjusted their schedules slightly to participate in real-time planning. This allowed us to keep collaboration inclusive and time-bound.
Early Friction and What We Learned
The first two CP sessions were admittedly clunky. Teams went well over the time limit—some sessions stretched to 8 or 9 hours—and struggled to select epics and features to focus on. We were still carrying residual structures from PI planning, and making this transition required clear intentionality from both product and engineering leads.
We also faced natural resistance to change. Some teammates quickly embraced the new approach, while others were unsure why we needed to move away from the familiar cadence. This was a learning moment for me as a product leader: it’s not enough to change the system—you have to explain why the change matters.
Making CP Work: Structure, Discipline, and Demo Culture
To create structure without bureaucracy, I introduced three practices that helped the team focus:
A clear agenda and schedule based on team locations (India, East, Central, and West US time zones) and priorities
A visible (and loud) timer during planning to help teams stay within their allotted time
Team demos showcase completed features from the previous CP, along with available data or production results, focusing on outcomes rather than outputs.
We also created a shared spreadsheet to track features per team, each linked to its expected benefit or outcome. Each CP planning session begins with an update from the previous CP and a review of current CP features.
This helped the team realize that many features were overestimated or carried across CPs. So we refined the guiding principle: each CP should contain independent, deliverable features that can be completed within the cycle. We prioritized fewer features with more focus and aimed to minimize work in progress.
Rather than constantly opening new epics, we continued building within existing epics unless a new one was essential. This helped maintain a more consistent strategy across cycles.
Addressing the Feedback
We received a mix of positive and constructive feedback as we progressed.
What worked:
The requirements became clearer and easier to understand within the CP rhythm.
Teams appreciated being able to respond quickly to user feedback and engagement data.
The planning format encouraged frequent iteration and adaptability.
What needed improvement:
Teams wanted a longer-term view—a 6-month roadmap—to connect short-term CP goals with strategic direction.
Features with complex integrations or dependencies were harder to test in isolation, making test-driven development difficult within a CP cycle.
Communication between product and engineering needs to improve to align priorities and trade-offs for each CP session.
We addressed these concerns by:
Providing a 6-month strategic outlook, while still allowing features to be scoped and adjusted within each CP.
Identifying dependencies earlier and breaking them down into self-contained, testable chunks.
Fostering tighter collaboration between product and engineering during the one-week pre-planning phase.
Where We Are Now
By July, our most recent CP session wrapped up in under five hours—a huge improvement! Teams came prepared with clearly defined inputs and thoughtful prioritization. And more importantly, there was genuine excitement around demoing their work and sharing progress.
As the rhythm became familiar, the team built confidence, speed, and discipline.
The CP model isn’t perfect—and it’s not for every team—but for our fast-moving, AI-focused product team, it brought us closer to our goals: faster feedback loops, stronger alignment, and higher ownership across the board.
Final Thoughts
This transition wasn’t just a process change—it was a leadership challenge. As I led the shift, I had to listen closely, adapt based on feedback, and bring the team along every step of the way. Change can feel risky, but if the process starts to get in the way of outcomes, it’s worth asking how the system can evolve.
We’re still learning. But we’ve built a foundation that allows us to move faster, experiment confidently, and stay aligned—one CP at a time.