From Roadmap to PI Board: One Continuous Planning Flow
Your next PI can take shape continuously, long before the planning event begins.
Your next PI can take shape continuously, long before the planning event begins.
Most organizations know when their next planning period is coming months in advance. That period may be a Program Increment, a quarterly planning cycle, or, in SAFe 6.0 terminology, a Planning Interval. In this article, we use PI as a simple shorthand for that planning period.
Yet the actual work of building that PI often starts much later. A roadmap may show what is expected in the next quarter. Product teams maintain candidate Features in Jira or Azure DevOps. Priorities are discussed in spreadsheets and presentations. Architecture, portfolio and product teams refine work in their own meetings and boards.
Then PI Planning gets closer, and everything has to be brought together. Which Features are really in scope? Which ones are ready? What changed since the roadmap was created? Which version of the priority list is current?
The problem is not a lack of planning. The problem is that each stage of planning often happens somewhere different. Roadmaps, prioritization, refinement and PI Planning become separate activities instead of one continuous process.
There is another way to approach it. Instead of treating the roadmap, prioritization, refinement and PI Planning as separate exercises, the next PI can take shape as one continuous planning flow, months before the planning event itself.
Start with the future PI
Long-range planning should not stop at a roadmap showing dates and high-level intentions.
If you already know the next PIs are coming, create them on the PI Roadmap before their PI Boards exist. This gives portfolio, product and program teams a common planning horizon across current and future PIs.
At this stage, a future PI does not need to be complete. It may begin with only a few strategic initiatives or candidate Features. Over time, more work can be considered, priorities can change and items can move between future periods.
The important difference is that there is already a place for the future plan to develop. Instead of suddenly assembling the next PI a few weeks before planning, the organization can build it gradually as decisions are made.
Turn the roadmap into real priorities
Knowing that a Feature might belong in a future PI does not mean it should automatically make the cut. There may be dozens of candidate Features competing for limited capacity.
This is where the Backlog becomes part of the planning process. Rather than maintaining a separate spreadsheet of candidates, portfolio and product teams can work with the actual hierarchy coming from Jira or Azure DevOps. Features can be compared, ranked and associated with current or future PIs as priorities become clearer.
Teams can also use approaches such as WSJF to evaluate Features against business value, urgency, risk reduction and size. The important part is not simply having another prioritization view. It is that prioritization directly shapes the future PI.
A PI that initially contains twenty or thirty possible Features may gradually narrow as decisions are made. Some work moves forward. Some moves to a later PI. Some needs more information before a decision can be made.
The roadmap and the priority discussion are no longer disconnected.
Priority is only the beginning
A high-priority Feature is not necessarily ready for PI Planning. It may still require product refinement, architectural input, business approval, dependency analysis or another form of preparation.
Those activities rarely happen within a single team. A Feature might begin with a portfolio group, move to product management, require architectural review and then be prepared by a delivery organization.
Connected Kanban boards can turn what is often a series of disconnected hand-offs into a visible preparation flow. Each group can work in the view that makes sense for them, while the same Feature continues moving forward.
A portfolio board might focus on investment decisions. A product board might focus on discovery and refinement. An architecture board might focus on feasibility and technical readiness.
The same work can move through those different views without creating another copy at every stage. When a Feature reaches the agreed point in one part of the organization, it can continue into the next team's working view while remaining the same Jira, Azure DevOps or Kendis item.
The result is more important than the mechanics: you can see work becoming ready. Instead of asking whether Product reviewed a Feature, whether Architecture received it or whether Portfolio approved it, the preparation process itself becomes visible.
Let the PI build as decisions are made
This changes what it means to prepare a PI.
The future PI is already visible on the roadmap. Candidate Features are being prioritized in the Backlog. Those Features continue through the relevant refinement and readiness stages. As the organization gains confidence about what belongs in the PI, that work can be assigned to it.
The PI gradually becomes more complete, not because somebody is manually rebuilding a planning spreadsheet every Friday, but because the decisions being made throughout the organization are shaping the same plan.
Instead of asking: "What are we taking into the next PI?"
The conversation becomes: "Here is the work we have prioritized and prepared. Now let's plan how we will deliver it."
That is a very different starting point.
The PI Board becomes the destination, not the starting point
Traditionally, creating the PI Board can feel like the beginning of PI preparation. It should be closer to the end of it.
Once the future PI is ready for detailed planning, it can become the PI Board, with the work already selected for that PI available for teams to plan.
Teams can then spend their time on the things PI Planning is actually meant for: sequencing work, understanding capacity, identifying dependencies, discussing risks, agreeing objectives and making commitments.
They are not starting from an empty board. They are continuing a planning process that has already been running for weeks or months.
From planning events to a planning flow
The bigger change is not any individual screen or board. It is the relationship between them.
Instead of treating roadmap planning, prioritization, refinement and PI Planning as separate activities, they become stages of the same journey:
- Plan future PIs
- Prioritize Features
- Refine and prepare
- Build the PI
- PI Planning
While the current PI is being delivered, the next one can already be moving through prioritization and preparation. The PI after that can already exist on the roadmap with early candidates beginning to form.
There is no need to stop at the end of every quarter and reconstruct the planning process from the beginning. The plan continues to evolve.
One planning journey, from intent to execution
When future PIs exist early, priorities can shape them continuously. When refinement is connected to prioritization, teams can see not only what matters, but what is actually becoming ready. And when that prepared work flows into the PI Board, PI Planning no longer needs to begin by reconstructing the plan.
The roadmap, Backlog, connected Kanban boards and PI Board are not separate planning exercises. They are different stages of the same planning journey, built around the same work.
The next PI is already taking shape before planning day arrives, with one plan moving continuously from roadmap to PI Board.
