PI planning gets a bad reputation because many organisations use it badly.

That is not the same as saying the idea is bad.

At its best, PI planning is one of the few moments where strategy, architecture, product intent, delivery capacity, and team reality are forced into the same conversation. That matters. Most delivery problems are not caused by a lack of effort. They are caused by hidden dependencies, unclear priorities, brittle architecture, competing incentives, and leaders mistaking confidence for evidence.

SAFe describes PI planning as a cadence-based event for an Agile Release Train, aligning teams and stakeholders to a shared mission, vision, and committed plan. The typical pattern is a two-day event every 8 to 12 weeks (Scaled Agile Framework).

That definition is useful, but incomplete.

The real value of PI planning is not the plan. The value is the collision between the plan and reality.

If your PI planning event does not reveal uncomfortable truths, it probably has not worked.

The plan is not the product

The most common failure mode is treating PI planning as a delivery contract.

Teams leave the event with objectives, dependencies, milestones, and a set of commitments. Leaders see a board full of coloured lines and assume the machine is now under control. It looks like alignment. It feels like progress. It gives everyone something to point at in the next governance meeting.

Then the real work starts.

A platform dependency takes longer than expected. A security review exposes a design flaw. A third-party integration behaves differently in production. A team loses capacity. A business stakeholder changes priority because a customer deal moved. A legacy system does what legacy systems do: it reminds everyone that PowerPoint architecture and production architecture are not the same thing.

None of this is unusual. This is normal delivery.

The problem starts when the PI plan becomes more sacred than the evidence emerging during the PI.

Agile planning should create direction, not denial. If the plan cannot absorb learning, it is not an Agile plan. It is a quarterly waterfall plan with better branding.

Why PI planning exists in the first place

Large organisations have a coordination problem.

Small teams can plan through conversation, proximity, and fast feedback. Larger systems cannot rely on informal alignment alone. The moment multiple teams, shared platforms, external suppliers, architecture constraints, funding boundaries, regulatory needs, and customer commitments enter the picture, unmanaged coordination becomes expensive.

Atlassian frames PI planning around roadmap alignment, goal setting, prioritisation, open communication, user personas, user activities, and release priorities (Atlassian).

That is the right territory.

PI planning should answer five practical questions:

• What outcome matters most in the next planning interval?
• Which teams need to collaborate to make it happen?
• What dependencies could block the work?
• What trade-offs are we making deliberately?
• What evidence will tell us we need to adjust?

That last question is the one many organisations skip.

They talk about dependencies. They talk about risks. They talk about confidence votes. But they do not define the signals that would cause them to re-plan. Without that, PI planning becomes a confidence ritual.

Dependencies are not admin. They are architecture.

I have spent enough years around infrastructure, platforms, release trains, change windows, service ownership, and operational risk to know this: dependencies are where strategy goes to get mugged.

A dependency is not just a line between two cards. It is a statement about how your organisation is structured.

Conway’s Law says organisations design systems that mirror their communication structures, and the practical implication is that team boundaries and communication paths shape the systems they produce (Splunk).

That is why PI planning can be useful. It gives you a temporary x-ray of the organisation.

If every feature depends on the same platform team, you do not have an execution problem. You have a constraint.

If every customer-facing change requires three handovers, two architecture boards, a data team, a security review, and a release manager, you do not have a velocity problem. You have a flow problem.

If the same dependency appears in every PI, you do not have a planning problem. You have an operating model problem.

PI planning should make these patterns visible. But visibility is not the same as resolution. Writing a dependency on a board does not remove it. Naming a risk does not reduce it. Assigning an owner does not create capacity.

The question is not, “Did we capture the dependency?”

The question is, “What are we changing so this dependency becomes less expensive next time?”

PI planning fails when it becomes theatre

You can usually spot PI planning theatre quickly.

The business context is vague. The roadmap is already fixed. Teams are asked to estimate work they did not shape. Architecture concerns are parked because they are “too detailed for this session”. Risks are softened so the confidence vote looks healthy. Stretch objectives become hidden commitments. The final readout sounds crisp, but the people doing the work know the plan is fragile.

That is not alignment.

That is compliance.

The event may still produce outputs. It may produce objectives, boards, risks, and dependencies. But those artefacts are not evidence of alignment. They are evidence that a meeting happened.

The DORA research is useful here because it keeps dragging the conversation back to delivery capability, culture, user focus, loosely coupled teams, documentation, continuous improvement, and fast feedback (DORA). DORA’s 2023 report found that generative organisational cultures correlate with 30% higher organisational performance, and that teams prioritising user needs achieve 40% higher organisational performance (DORA).

That matters because PI planning without culture is theatre.

If people cannot challenge assumptions, your dependency board is fiction.

If teams cannot say “we do not have capacity”, your estimates are fiction.

If product goals are not tied to user outcomes, your objectives are fiction.

If leaders punish changes to the plan, your inspection and adaptation loop is fiction.

The ceremony is not the capability.

What good PI planning feels like

Good PI planning is not comfortable.

It is constructive, but it is not comfortable. The right conversations expose trade-offs early enough to do something useful with them.

Good PI planning sounds like this:

• “We can do A or B properly, but not both.”
• “This objective depends on an API change the platform team has not prioritised.”
• “The customer outcome is clear, but the solution is still too assumed.”
• “This architecture decision will speed up this PI but create operational cost later.”
• “We need a spike before we commit to the delivery objective.”
• “The risk is not mitigated. It is accepted. Let’s be honest about that.”

Bad PI planning tries to remove uncertainty by forcing certainty into the room.

Good PI planning reduces uncertainty by making it discussable.

That distinction matters.

The three useful outputs

Most PI planning events produce too many artefacts and not enough decisions.

I would focus on three outputs.

Clear outcomes

A PI objective should not be a renamed feature list.

“Deliver customer dashboard phase two” is not an outcome. It is an output. It may be necessary, but it does not explain the change you expect to see.

A stronger objective is closer to: “Reduce manual account reconciliation effort for operations users by removing the top three duplicate data checks.”

That gives teams a decision filter. It gives stakeholders something testable. It also allows scope to move without losing the point of the work.

This is where Atlassian’s emphasis on user personas, user activities, and prioritising the most valuable release stories is useful, because it forces planning back towards user need rather than internal activity (Atlassian).

Honest constraints

Capacity is a constraint. Architecture is a constraint. Security is a constraint. Supplier availability is a constraint. Operational readiness is a constraint. Cognitive load is a constraint.

None of these constraints are excuses.

They are design inputs.

If a plan ignores constraints, the organisation has not become ambitious. It has become careless.

The best planning conversations do not ask, “How do we make the board green?”

They ask, “What has to be true for this to work?”

Re-planning triggers

This is the missing piece in many PI events.

Teams need to know what would cause the plan to change.

Examples:

• If the platform dependency is not available by the end of sprint one, switch to the fallback integration path.
• If the discovery spike invalidates the assumed user behaviour, stop build work and reframe the objective.
• If production defect volume exceeds an agreed threshold, reduce feature scope and protect reliability.
• If the regulatory interpretation changes, escalate the decision rather than absorbing it inside the team.

This is not pessimism. It is operational discipline.

Plans that define re-planning triggers are more credible than plans that pretend nothing will change.

The leadership test

PI planning tests leadership more than it tests teams.

Teams usually know where the bodies are buried. They know which dependency is fragile. They know which objective is inflated. They know when a feature is being pushed because someone promised it before understanding the work.

The leadership question is simple: do you want the truth early, or the surprise late?

If leaders use PI planning to extract commitment, teams will learn to manage the optics.

If leaders use PI planning to expose constraints, teams will bring reality into the room.

That one distinction changes the whole event.

The Scaled Agile description talks about aligning development to business goals through business context, vision, and team and ART PI objectives (Scaled Agile Framework). That alignment only works if business leaders are willing to make trade-offs in the room, not after the event when the difficult choices have been pushed down into delivery teams.

You cannot delegate prioritisation pain to teams and then call it empowerment.

A practical PI planning checklist

Before the event, ask:

• Is the business context specific enough to guide trade-offs?
• Are the top objectives tied to user or operational outcomes?
• Is the backlog ready enough for meaningful planning?
• Do teams understand their real capacity?
• Are architectural constraints visible?
• Are the right decision-makers available?

During the event, ask:

• Which dependencies repeat across multiple teams?
• Which objectives are actually outputs pretending to be outcomes?
• Which risks are being softened for political reasons?
• Where are teams being asked to absorb uncertainty they do not control?
• What would make us change the plan?

After the event, ask:

• Did the plan survive first contact with delivery?
• Which assumptions were wrong?
• Which dependencies cost us the most time?
• Which decisions were made too late?
• What should we remove, simplify, or restructure before the next PI?

If you cannot answer those questions, the event may have been well facilitated, but it has not improved the system.

The uncomfortable truth

PI planning is not a maturity badge.

It does not make an organisation Agile. It does not fix weak product ownership. It does not compensate for overloaded platform teams. It does not remove architecture debt. It does not turn output roadmaps into outcome strategy. It does not make dependencies disappear.

What it can do is make the real system visible.

That is valuable.

But only if the organisation has the courage to act on what it sees.

The best PI planning events are not the ones where every team leaves with a polished board and a high confidence vote. The best ones are where the organisation learns something important early enough to change course.

That is the standard I would use.

Not whether the ceremony was followed.

Whether the next eight to twelve weeks became more honest, more focused, and easier to adapt.