Estimating Cross-Team Initiatives in PI Planning

What's really being asked

This question tests your ability to facilitate a complex, collaborative estimation process at scale. The interviewer isn't looking for a single number; they are evaluating your leadership and understanding of systems thinking. They want to see if you can guide multiple teams to a realistic, risk-adjusted plan. The core principle being tested is that the people who do the work are the ones who plan the work. You are the facilitator, not the dictator, of the estimation process.

The full answer

A strong answer walks through a four-step, bottom-up process. First, describe the pre-planning work: the large initiative is decomposed by product managers and architects into smaller features, each provisionally mapped to a primary team. Second, explain the team breakouts: during PI Planning, each team takes their features, breaks them down further into stories, and estimates those stories in points based on their own, separate velocity and capacity. Third, detail the dependency mapping: teams use the ART or program board to visualize dependencies, often with string or digital lines, showing which stories block other stories on other teams. This makes the critical path visible. Finally, explain the synthesis and commitment: you review the board, sum the effort per team against their capacity, identify risks like overloaded teams or long dependency chains, and facilitate a confidence vote (like a Fist of Five) to get buy-in on the resulting plan.

The mistakes people make

The most common red flag is giving a single, top-down estimate, such as, "That sounds like a 200-point project." This completely ignores the complexity of dependencies and the unique velocities of different teams. Another major error is simply summing the story points from all teams without mapping dependencies; 70 points of work can take three sprints if it's sequential, not one. Also, presenting a plan where a team is allocated 50 points of work when their known capacity is 30 shows a lack of practical experience. Finally, suggesting an architect or manager should provide the estimates for the teams is a fundamental misunderstanding of agile principles.

What usually comes next

Expect questions like: "What do you do if the final estimate far exceeds the business's expectations?" (Your answer should focus on negotiation, descope, and managing expectations, not on pressuring teams to work faster). Or, "How do you handle a critical dependency on a team outside of your Agile Release Train (ART)?" (Treat them as a supplier, get commitments early, and flag it as a major risk). Another common one is, "How do you account for unplanned work?" (Teams should not be planned to 100% capacity; a 10-20% buffer is standard).

A concrete example

For a 'Mobile Checkout' initiative, we'd first break it into features like 'UI Redesign,' 'API Gateway Update,' and 'Payment Processor Integration.' In PI Planning, the UI team estimates their work at 40 points, API at 25, and Payments at 20. On the program board, we'd draw a line from the API team's 'New Endpoint' story in Sprint 2 to the UI team's 'Render Cart' story in Sprint 3. This shows that while the total effort is 85 points, the end-to-end value can't be delivered before Sprint 3 due to this dependency. We'd also check that 40 points doesn't exceed the UI team's PI capacity of, say, 45 points.