Estimating large, cross-team initiatives in PI Planning
Tests your ability to facilitate collaborative estimation. Break the initiative into features for teams to estimate, then use an ART board to map dependencies. A red flag is providing a single, top-down number without team input.
What's really being asked
This question tests your ability to facilitate planning in a complex, multi-team environment. The interviewer is looking for more than just knowledge of SAFe terminology; they want to see if you can lead a collaborative process, break down ambiguity, and manage dependencies. Your answer should demonstrate that you empower teams to create a realistic, shared plan rather than dictating a top-down estimate.
The full answer
A strong answer walks through a four-step process. First, DECOMPOSITION: Before or during PI Planning, the large initiative (Epic) is broken down with Product Managers and Architects into smaller Features, each assignable to a specific team. Second, TEAM-LEVEL ESTIMATION: During breakout sessions, each team estimates only the features assigned to them, using their own relative story points and historical velocity. This respects the principle that the people doing the work should plan it. Third, DEPENDENCY MAPPING: As teams plan their sprints, they identify dependencies on other teams. These are visualized on the ART Planning Board, often using strings or digital lines to connect stories between team swimlanes. This is the most critical step for a cross-cutting initiative. Fourth, AGGREGATION AND SEQUENCING: The Release Train Engineer (RTE) facilitates a review of the board to see the full, sequenced plan. The outcome is not a simple sum of points, but a visual forecast of which features will be delivered in which iteration, highlighting the critical path.
The mistakes people make
The most common red flag is suggesting a top-down estimate, like "I'd get the architects to scope it out and tell the teams it's a 6-month project." This ignores the core tenets of agile planning. Another mistake is simply summing the story points from all teams (e.g., 40 + 50 = 90 points) without accounting for dependencies, which dictate the actual timeline. A candidate who insists on using man-days instead of abstract story points during the planning event also shows a misunderstanding of the process. Finally, failing to mention a central artifact like the ART Planning Board indicates a lack of experience with the 'multi-team' aspect of the problem.
What usually comes next
Expect questions like: "What if a team can't estimate a feature because of too many unknowns?" (A good answer is to create a 'Spike' or research story for the first sprint to de-risk it). Or, "How do you resolve a dependency conflict where two teams disagree on the sequence?" (The RTE facilitates a negotiation, potentially involving Product Management to re-prioritize). Finally, "How do you communicate this plan to stakeholders who want a fixed date?" (Explain you have a high-confidence forecast for the 8-12 week PI, with lower confidence beyond that, and use the board to show them the complexity).
A concrete example
Consider an initiative to "Implement MFA for all customer accounts." This involves the Auth, Frontend, and Mobile teams. In PI Planning, it's broken down. The Auth team has a Feature to build the MFA service (30 points). The Frontend team has a Feature to build the web UI flow (20 points). The Mobile team has a Feature for the native mobile flow (25 points). On the ART board, you'd see a dependency string from the Frontend and Mobile features pointing to the Auth feature. The Auth team plans their work for sprints 1 and 2. The Frontend and Mobile teams can't start their main build until sprint 3, when the service is ready. The plan shows a 3-sprint timeline, not just a sum of 75 points.
Interview question
When estimating a large, cross-team initiative during PI Planning, which approach is most effective?
- a.Each team estimates their assigned features, and the total initiative estimate is the sum of all team story points.
- b.The initiative is broken into features, teams estimate their assigned work, and dependencies are mapped on the ART board to create a sequenced plan.Correct
- c.Senior leadership provides a fixed deadline, and teams then work backward to allocate tasks within that timeframe.
- d.Product Managers and Architects define a single, top-down estimate for the entire initiative.
Why? this is the answer
The most effective approach involves decomposing the initiative, having teams estimate their specific features, and critically, mapping dependencies on the ART board to create a sequenced forecast. Simply summing individual team estimates (Option A) is a common mistake as it ignores the impact of dependencies on the overall timeline.
Just read this? Test yourself on what you have been reading.
Read the original → framework.scaledagile.com
- #agile
- #safe
- #estimation
- #planning
- #scrum
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles