01. Reviewing draft plans at an ART that builds software for clinical laboratories, the System Architect sees that one team has planned a Feature in a way that will break an audit-logging requirement the organization has committed to its regulator. The team's plan is otherwise sound and the team is confident about it.
What is the right response during PI Planning?
a) Let the plan stand for the PI and schedule an architecture review before release, so the team keeps the plan it is confident in and the logging gap closes before anything reaches a customer
b) Ask the Scrum Master or Team Coach to raise it as an impediment during the first iteration of the PI
c) Take the requirement to the team and Product Management now, as a constraint on that Feature, so the work it implies sits in the plan the team commits to
d) Add it to the ART Backlog as a Feature for the next PI
02. Features on an ART building a logistics tracking platform pass each team's definition of done and then fail repeatedly at the System Demo, because teams have made incompatible assumptions about a shared event schema. The System Architect proposes adding a standing Architectural Sync for the teams' technical leads.
How should the RTE respond?
a) Approve the new event and give it a timebox, since the ART has a genuine coordination gap and adding a forum is the least disruptive way to close it before the next System Demo.
b) Decline it and have the architect publish the event schema as a standard the teams must follow, with conformance checked at each Iteration Review.
c) Ask the System Team to own the event schema, since it maintains the platform the teams integrate on.
d) Decline the new event and use the sync cadence the ART already has, so the schema's content and priority go to the PO Sync and the integration failures to the Coach Sync.
03. At draft plan review on a hospitality booking ART, a team reports that its loyalty-redemption Feature needs a new endpoint from the payments team, and that the two teams have spoken and the payments team has agreed to help. Nothing about the endpoint appears on the program board, and neither team's plan says when it arrives.
What is missing, and why does it matter?
a) Nothing is missing, since the two teams have agreed between themselves, and ART Sync gives them a standing forum in which to settle the timing and the sequence as the PI runs
b) The iteration the endpoint lands in, agreed by the payments team and drawn on the program board, without which neither plan can be checked against the other
c) The dependency should be raised as a risk and ROAMed at the final plan review, since the payments team may not deliver what it has promised once its own plan comes under pressure
d) The loyalty team should sequence its dependent stories into the last iteration, giving the payments team the whole PI to deliver
04. On an ART building a claims-processing platform, the System Architect has an Enabler that must land this PI: without it, three Features planned for the following PI cannot be built. Two Product Owners have each ranked it below their own teams' Features for the coming iterations, and the Enabler has still not been pulled.
Where should the architect take this?
a) The Coach Sync, so that the Scrum Master/Team Coaches can surface the stalled Enabler as an impediment and coordinate their teams to pull it next iteration.
b) The Iteration Review, where each team demonstrates its increment and the architect can show what the missing Enabler is blocking.
c) Directly to the two Product Owners, since each of them owns the priority of the backlog their own team pulls from.
d) The PO Sync, where scope, priority and content are aligned across the ART's teams.
05. Draft plan review at a medical devices ART has just ended. The System Architect knows that four of the planned Features assume a validated test environment the runway does not yet provide, and that building it will take a substantial share of the PI's capacity. Product Management ranked those Features believing the environment already existed.
What should the architect do that evening?
a) Ask the Business Owners to decide what to trade at that evening's Management Review and Problem-Solving, where scope and priorities can still change
b) Work with the affected teams through the evening to design a lighter-weight validated environment that fits inside the capacity the plan already allows for those Features
c) Record the shortfall in the Solution Intent as a constraint and let the teams find the sequencing consequences for themselves during the day two breakouts
d) Add a Compliance Enabler to the ART Backlog for the next PI
06. An ART has finished the final plan review on day two of PI Planning. Risks have been addressed and the PI Objectives are posted on the wall.
What does the confidence vote that follows ask each participant to express?
a) Agreement that the stories in each team's plan are correctly estimated and sequenced across the iterations of the PI
b) Confidence that the ART, taken as a whole, can meet its PI Objectives
c) Approval of the architecture vision and of the Enabler work the System Architect presented at the start of day one
d) A judgment on whether the business value the Business Owners assigned to the objectives is fair to the teams
07. Halfway through a PI on a logistics tracking ART, teams building the shipment-events service find that the event store named in the Solution Intent cannot hold the retention window at the volume the pilot customers actually generate. Two teams have already worked around it in different ways.
What does SAFe expect the System Architect to do with the Solution Intent?
a) Update the variable part of the Solution Intent with the decision execution has now made clear, and tell both teams so they converge on one approach.
b) Leave the Solution Intent as it stands, record the workarounds as technical debt, and let each team keep the route it has found, since the intent describes what was decided.
c) Freeze the Solution Intent until Inspect and Adapt, when the ART can review the evidence together.
d) Have each team document its own workaround.
08. During the final plan review of a retail e-commerce ART, four teams raise risks that read very differently: promotion pricing may be stale at checkout, the catalog page may time out under campaign load, the loyalty balance may disagree with the receipt, and the returns flow may double-credit. The System Architect sees that all four run through the same shared pricing service, which has no consistent read model.
What should the architect do?
a) Let each team ROAM its own risk, since each team owns the Feature affected and is best placed to judge the exposure it carries.
b) Accept all four, and plan an Enabler for the read model in the next PI.
c) Record the pattern as an improvement item so the problem-solving workshop at Inspect and Adapt can find the root cause with the whole train present.
d) Consolidate the four entries into one Owned technical risk on the pricing service's read model, take ownership as the architect closest to that design, and put the cost of leaving it unaddressed in front of the ART's leadership so scope can be adjusted before the plan is committed.
09. Lean Portfolio Management has approved an Enabler Epic whose MVP will run a candidate database technology at production volumes, to establish whether it can meet the Solution's throughput requirement before the platform is committed to.
Which kind of Enabler is this?
a) An Exploration Enabler, since its output is evidence.
b) An Infrastructure Enabler, since it changes the platform the Solution runs on.
c) An Architecture Enabler, since it evolves the design of the Solution itself.
d) A Compliance Enabler, since a throughput target is a quality the Solution is held to.
10. Two iterations into the PI, a team on a regional insurer's claims ART finds that the fraud-scoring service it planned to call is being rebuilt by a different ART, and the interface it planned against will not exist this PI. The dependency was not on the program board.
What should the System Architect do next?
a) Record the missing interface as a technical debt item and let the team plan around it until the next PI Planning event, when the dependency can be placed on the program board.
b) Ask the Product Owner to move the affected stories into the Innovation and Planning Iteration, where the schedule pressure is lower.
c) Escalate to the portfolio so that the two ARTs can be coordinated centrally.
d) Take it directly to the other ART's System Architect and RTE, so both trains renegotiate what each can now depend on while iterations remain.