How would you estimate a cross-cutting initiative in PI Planning?

What's really being asked

The interviewer wants to see if you understand how to handle ambiguity and cross-team coordination in a scaled agile context without collapsing back to waterfall habits. Specifically they are looking for your ability to decompose a large technical initiative into manageable, team-owned pieces while preserving the SAFe principle that the people who do the work plan the work. They also want to know whether you treat dependencies as first-class citizens and whether you protect capacity rather than treating estimates as promises.

The full answer

First, the candidate should mention splitting the initiative into enabler features or stories with clear interfaces and acceptance criteria so that each team can see its own boundary. Second, they should emphasize that estimation happens at the team level using normalized story points or capacity percentages rather than having a single architect dictate a number. Third, they should describe visualizing cross-team dependencies on the ART planning board so that integration points and sequencing risks are visible to everyone. Fourth, they should talk about matching demand to capacity and using the Innovation and Planning iteration as a buffer for integration, unknowns, and final hardening. Fifth, a strong answer notes that committed PI objectives should reflect what teams realistically believe they can deliver, not a best-case fantasy.

The mistakes people make

A red flag is suggesting that one lead architect or a central team produces the estimate and hands it down to the teams. Another red flag is proposing to skip PI Planning and handle the initiative entirely offline, which breaks alignment and transparency. Candidates who suggest estimating the entire initiative as one big bucket of points without team-level decomposition are also showing they do not understand flow or dependency management. Finally, treating the IP iteration as slack that can be filled with extra features rather than reserved for planning and integration is a common mistake.

What usually comes next

The interviewer may ask how you would handle a team that claims it cannot estimate because the requirements are too vague. They might also ask what you would do if the sum of all team estimates exceeds the available PI capacity. Another follow-up is how you track progress of a cross-cutting enabler across multiple teams during the PI. You should be ready to discuss spikes, backlog refinement, and the role of the System Architect or RTE in facilitation rather than estimation.

A concrete example

Suppose an ART needs to migrate a monolithic authentication service to a new identity provider. Team A owns the user-facing API changes, Team B owns the backend token validation logic, and Team C handles the database schema migration. In PI Planning, the initiative is split into three enabler features with interface contracts agreed upon in the architecture runway. Each team estimates its own enabler in normalized story points during the breakout sessions. Dependencies are drawn on the ART board showing that Team C must deliver the schema changes by iteration two before Team A can integrate the new API in iteration three. The teams commit to PI objectives that include the migration scope but reserve twenty percent of the IP iteration for end-to-end integration testing. When the board shows Team B is over capacity, scope is negotiated down with the Product Manager rather than forcing an optimistic commitment.