PI planning is one of the best documented events in enterprise agile. The agenda is published, the roles are named, and the outputs are specified. That is not where it fails. It fails before the room, in how ready the teams and backlog were, and after it, in whether two days of commitments survive the tooling. The layer that carries those outputs into the next ten weeks is covered in our guide to scaling agile with Jira Align.

Planning Interval or Program Increment

The acronym is stable, and the words behind it are not. Scaled Agile's current site defines PI as a Planning Interval, "a cadence-based timebox in which Agile Release Trains deliver continuous value to customers in alignment with PI Objectives". Atlassian's Jira Align documentation uses program increment throughout, including as a stated prerequisite for the program board. Both are current, and which you meet depends on whether you are reading the method or the tool.

What PI planning is

PI planning is a cadence-based event that aligns an entire Agile Release Train to a shared mission and plan. Scaled Agile describes a two-day event for the whole ART, held every 8 to 12 weeks and led by the Release Train Engineer. It is the core event of SAFe.

The timebox has a fixed shape. A PI runs 8 to 12 weeks and most commonly contains four or five development iterations followed by one Innovation and Planning iteration. The planning event sits inside that IP iteration, which gives teams room to plan without stopping delivery. Scaled Agile is explicit that this pattern is a suggestion rather than a rule, and that shorter durations are preferred.

Attendance is the whole train: the agile teams with their scrum masters, product owners and developers, plus product managers, business owners, system architects and the RTE who runs the event. Co-location helps, though Scaled Agile states that real-time virtual planning works when everyone on the ART participates.

The two days

Day one opens on context. A business owner sets the strategic themes, product management presents the vision and feature priorities, system architects cover the architecture vision and enablers, and the technical leader covers changes to development practices and the delivery pipeline.

Then the teams break out, and this is the long part. They estimate the capacity they will have in each iteration, then size and sequence stories until that capacity is exhausted. For new trains, a story over eight points gets split. Coach sync checkpoints run hourly, five to ten minutes each, so interdependencies and impediments surface while there is still time to act. The day closes with a draft plan review and an evening management review where scope gets renegotiated.

Day two opens with those decisions communicated back. Teams refine and finalize their PI objectives as SMART objectives, and business owners assign business value to each one, including the uncommitted ones. The board is brought up to date with features, milestones and dependencies, and the day closes with the final plan review, the risk pass, and the commitment.

What the event has to produce

Scaled Agile names four outcomes, and an event that delivers three of them has not finished. The train leaves with a set of committed PI objectives and a visible planning board showing features, milestones and the dependencies between teams. Every remaining ART risk is addressed through ROAM, which sorts each one as resolved, owned, accepted or mitigated. And the fourth outcome is alignment across the train, which is the one nobody can put in a tool.

Four signals the event did not work

The first is over-scoping. Scaled Agile's own guidance names teams carrying 50 to 100 percent too much work as a recognized failure, and says that if this is still visible on day two the plan is not ready for the final commitment and needs reworking until it is realistic.

The second is the vote. A confidence vote below three fingers means the work is incomplete, and the guidance is unambiguous: scope and resources get adjusted and planning continues, because alignment and commitment are valued over holding the timebox.

The third shows up in the architecture conversation. When teams plan without accounting for technical dependencies and enablers, the plan looks clean and fails in iteration three. The fix is structural rather than motivational, which is why system architects present enablers on day one.

The fourth only appears afterward, on the board. Atlassian's Jira Align documentation gives a direct diagnostic: if feature delivery shifts out of the early sprints and many features come due in the final two, that indicates an immature or unhealthy program. It is the most useful single read a planning board offers.

Where the tooling carries it

Two days of commitments have to live somewhere they can be tracked, or they decay into a slide deck by week three. In Jira Align the program board holds the plan. Jira Plans carries a Program Board of its own, and the choice between the two products is covered in our comparison of Jira Plans and Jira Align. Atlassian's documentation is clear that it is more than a schedule: it is an agreement between product management and the development teams about what will be delivered and when. Features, dependencies, objectives and milestones each carry their own symbol and color, so the state of the train is readable at a glance rather than assembled from status reports.

The program room sits around it and runs the PI. Program increment actual load is calculated as program story points loaded divided by program available capacity, with the same calculation at team level, which turns over-commitment from an argument into a number. Dependencies, impediments, risks and objectives each get their own widget, and the PI moves into execution when someone starts it.

Getting the first one right

The first PI planning event an organization runs is rarely about the event. It is about whether the operating model underneath it is real: whether portfolios and value streams are defined, whether the backlog is refined enough to plan against, and whether leadership will make scope decisions in the room rather than afterward by email.

We assess that before configuring anything, then set up the planning cadence, the hierarchy and the program boards so the event has somewhere to land. Holograph is an Atlassian Solution Partner with specializations in ITSM, Cloud, and DevOps, and this is Performance work: getting more from the Atlassian platform you already run. Whether delivery improves afterward is a separate question, and the four DORA metrics are the honest way to answer it.

If your first PI planning event is coming up, talk to us about Jira Align and we will start with a readiness assessment rather than a tool configuration.

Frequently asked questions

What is PI planning?

PI planning is a cadence-based event that aligns every team on an Agile Release Train to a shared mission and a committed plan. Scaled Agile describes a two-day event for the entire train, held every 8 to 12 weeks and led by the Release Train Engineer. It takes place during the Innovation and Planning iteration so that planning does not interrupt delivery.

How long is a PI?

A PI is a timebox of 8 to 12 weeks, most commonly four or five development iterations followed by one Innovation and Planning iteration. Scaled Agile treats this as a starting pattern rather than a rule and states a preference for shorter durations, so the right length depends on how quickly your trains learn from a cycle.

Who leads PI planning?

The Release Train Engineer leads and runs the event. Attendance is the whole train, from the agile teams through product managers, business owners and system architects. The business owner sets the business context and later assigns business value to each PI objective.

What are the outputs of PI planning?

Scaled Agile names four. The train leaves with a set of committed PI objectives, a visible planning board showing features, milestones and cross-team dependencies, every remaining ART risk addressed through ROAM, and increased alignment across the train. Teams capture the objectives and stories in their tooling afterward, and team objectives are aggregated into ART objectives.

What is the confidence vote?

At the end of day two, teams, business owners and ART leadership vote on their confidence in meeting the objectives using a show of hands, five fingers each. A vote below three means the work is incomplete, so scope and resources are adjusted and planning continues, because alignment and commitment matter more than finishing inside the timebox.

How is PI planning different from sprint planning?

They operate at different levels of the same system. Scaled Agile puts it directly: a PI adds cadence to an Agile Release Train in the same way an iteration does to an agile team. Sprint planning commits one team to one iteration. PI planning commits a train of teams to objectives spanning four or five.