Supporting ART Events practice questions

Finalizing the exact daily schedule for every developer on the team.

Why it fails: PI Planning is about high-level alignment and iteration planning, not micro-managing the daily schedule of individuals. Attempting to finalize a daily schedule is counter-productive and ignores the agile principle of responding to change as the team learns more during the execution of the PI.

Writing all the user stories for the team to save time during breakouts.

Why it fails: The Scrum Master should not write all the stories. Story writing is a collaborative effort between the Product Owner and the team. This collaboration ensures that the team has a shared understanding of the requirements and that the technical implementation details are considered from the start.

Determining the business value for each of the team's PI Objectives.

Why it fails: Business value is determined by the Business Owners, not the Scrum Master. The Scrum Master's role is to facilitate the interaction between the team and the Business Owners so that the value of the objectives is understood and accurately reflected in the team's final plan.

Individual team performance reviews.

Why it fails: PI Planning is a forward-looking planning event, not a performance review. Performance management is handled through different organizational processes. The focus here is on alignment, delivery, and shared commitment to the business goals, rather than evaluating the past performance of individual team members.

A detailed project plan with daily milestones.

Why it fails: Agile planning avoids the rigidity of detailed project plans with daily milestones. Instead, SAFe uses iterations and PI Objectives to provide flexibility. A daily-milestone approach would be too fragile and would not allow the team to adapt to the complexities and unknowns of software development.

The Architectural Runway Roadmap.

Why it fails: While architecture is discussed, the Roadmap is typically an input to or a separate artifact from PI Planning. The planning event focuses on the immediate execution of features for the upcoming PI, using the existing runway rather than creating the entire roadmap during the two-day session.

Overlooked.

Why it fails: Overlooked is not a category in ROAM. The goal of the ROAM session is to ensure that no risks are overlooked. Every identified risk must be categorized as Resolved, Owned, Accepted, or Mitigated to ensure there is a clear understanding of how it will be handled.

Reassigned.

Why it fails: While risks can be 'Owned' by someone else, 'Reassigned' is not the standard SAFe term. Using the correct ROAM terminology is important for clarity across the ART, ensuring everyone understands the level of responsibility and the status of the risk mitigation efforts.

Minimized.

Why it fails: While the goal might be to minimize risk, 'Minimized' is not one of the four official ROAM categories. The term 'Mitigated' is used instead to describe the proactive steps taken to reduce the risk's potential negative impact on the Program Increment's goals and objectives.

PI Planning

Why it fails: PI Planning is a separate event that occurs after the Inspect and Adapt event has concluded. While I&A outputs feed into PI Planning, the planning itself is not a component of the I&A event but rather the start of the next cycle in the SAFe continuous delivery pipeline.

Solution Demo

Why it fails: The Solution Demo is an event specific to the Large Solution Level, not the ART level. While similar in nature to the System Demo, it involves multiple ARTs and Suppliers and is not one of the three standard components of the Program Level Inspect and Adapt event.

Move Feature Beta to Iteration 1.1 immediately to align with the dependency.

Why it fails: Moving Feature Beta to an earlier iteration might not be possible if the team does not have the capacity. While it resolves the dependency sequence, it could create an over-commitment issue. The Scrum Master must first facilitate a discussion to see if the dependency can be moved earlier instead.

Request that the System Architect remove the dependency from the board.

Why it fails: Requesting the Architect to remove the dependency is often unrealistic as dependencies are usually based on technical requirements. While architectural changes can sometimes simplify work, the Scrum Master should focus on managing the existing workflow and coordination rather than trying to unilaterally change the technical design of the solution.

Assign the dependency to a different ART to reduce the burden on Team A.

Why it fails: Assigning the dependency to a different ART is an escalation that should only occur if the current ART lacks the skills. Most dependencies are internal to the train, and the Scrum Master's role is to facilitate collaboration within the train before seeking outside help from other trains.

The final ART Backlog

Why it fails: The final ART Backlog is not a team-level presentation item during the Draft Plan Review. The backlog is managed by Product Management and while it informs the planning, the review focuses on what the teams have pulled from it and how they intend to execute it, not the backlog itself.

Individual task lists

Why it fails: Individual task lists are too granular for the Draft Plan Review and should remain within the team's local planning environment. The purpose of the ART-level review is to focus on higher-level objectives and dependencies, not the specific day-to-day tasks that individual developers will perform during the iterations.

Team Velocity

Why it fails: Team Velocity is a local metric used for planning within the team and is not typically the focus of the ART-level Inspect and Adapt. While important for team-level retrospectives, the I&A event focuses on the performance of the entire Agile Release Train and its ability to deliver the Program Increment.

Individual Performance Reviews

Why it fails: Individual Performance Reviews are never part of SAFe events as they focus on the individual rather than the team or system. SAFe emphasizes collective ownership and system-level thinking, and bringing individual performance into an ART-level event would be destructive to the culture of collaboration and psychological safety.

Number of daily stand-ups held

Why it fails: The number of daily stand-ups held is a vanity metric that does not provide insight into the value delivered or the quality of the process. Metrics in SAFe should focus on outcomes, flow, and competency rather than simply counting the occurrences of prescribed meetings, which does not indicate agility.

The team achieved 100% predictability because they finished the uncommitted work

Why it fails: Predictability is not just about finishing work; it's about finishing the work you committed to. Because 'API Security' (a committed objective) was missed, the predictability score would be (10+0+5) / (10+8) = 83%, which is below a perfect score and indicates a missed commitment.

The uncommitted objective should have been given a Planned BV of zero

Why it fails: Uncommitted objectives still receive a Planned BV (to show their relative importance) and an Actual BV. However, for the calculation of the PI Predictability Measure, their Planned BV is excluded from the denominator to avoid penalizing the team if they do not reach those secondary goals.

Business Owners were incorrect to assign a 10 to Cloud Migration

Why it fails: The Scrum Master does not judge the Business Owners' value assignments. Instead, they use those values to measure how well the team delivered on the business's priorities. The focus remains on the team's execution and the accuracy of their planning rather than questioning the business's needs.

Escalate the integration issues directly to the Release Train Engineer to mandate stricter subsystem boundaries.

Why it fails: Escalating immediately removes team autonomy and bypasses the collaborative problem-solving mechanisms built into SAFe. The Scrum Master should first coach the teams to leverage the Scrum of Scrums and proactive planning to resolve integration challenges.

Cancel the current iteration and require all teams to completely rewrite their integration test suites.

Why it fails: Canceling an iteration is an extreme measure reserved for situations where the iteration goal has become entirely obsolete. Late integration is a common agile impediment addressed through better synchronization and continuous integration practices, not iteration cancellation.

Wait until the next Inspect and Adapt event to discuss these systemic integration failures during the problem-solving workshop.

Why it fails: Waiting for the Inspect and Adapt event delays corrective action for months, which severely jeopardizes the current Program Increment commitments. Immediate coaching and synchronization adjustments are required during the active execution phase.

Facilitate the technical design of cross-team interfaces and APIs.

Why it fails: Technical design is the responsibility of System Architects and the teams during their local synchronization or specialized design sessions. The SoS is a coordination meeting focused on visibility and dependencies, not a technical deep-dive. Bringing design discussions into the SoS can distract from the primary goal of ART synchronization.

Update the individual team's burn-down charts for the current iteration.

Why it fails: Updating team-level metrics like burn-down charts happens during the team's local Daily Stand-up or throughout the day. The SoS is a program-level event where the focus is on the ART's collective progress. Using this time for individual team administrative tasks is an inefficient use of the ART's time.

Assign new Stories to teams based on the remaining ART capacity.

Why it fails: Story assignment is handled by the teams and Product Management during PI Planning and through the Backlog Refinement process. The SoS is not a planning or task-assignment meeting. Its purpose is to synchronize existing plans and resolve issues that have arisen since the last synchronization event.

Ask Team Beta to move their work to Iteration 4 to provide more buffer.

Why it fails: Moving the work to Iteration 4 would actually make the problem worse, as Feature F-102 is currently scheduled for delivery in Iteration 3. Team Alpha needs the output earlier, not later. This suggestion ignores the delivery timeline and would guarantee that the Feature misses its target iteration on the Program Board.

Advise Team Alpha to begin their work anyway and use mock data until Team Beta finishes.

Why it fails: While mocking can sometimes help, the status 'delayed' for a dependency in the same iteration as delivery suggests a fundamental risk to the Feature. This approach avoids the necessary coordination and might lead to significant rework or integration failure. The Scrum Master must address the root cause of the synchronization issue.

Request that the System Architect redesign the Feature to remove the dependency entirely.

Why it fails: Redesigning a Feature in the middle of a PI is a drastic measure that should only be considered if all other coordination efforts fail. It is likely too late for such a change without significantly disrupting the ART. The immediate focus should be on managing the existing plan and communicating the impact to stakeholders.

Instruct Team Alpha to proceed with their plan assuming the dependency will be met, and adjust later if needed.

Why it fails: Proceeding without addressing the dependency risks delivering incomplete features and violates the principle of transparency. The Scrum Master should facilitate a resolution rather than ignore the reported impediment. This action could lead to integration issues and missed PI objectives.

Ask Team Alpha to reprioritize their backlog to remove the dependency on Team Beta's work entirely.

Why it fails: Reprioritizing to remove a dependency might be an option, but it should be a collaborative decision, not an immediate directive. The Scrum Master should first understand the situation and explore alternatives with Team Beta. Unilaterally removing the dependency could waste effort and disrupt the ART's plan.

Escalate the issue to the Release Train Engineer (RTE) immediately after the SoS meeting to ensure visibility.

Why it fails: While escalation may be necessary, the SoS is designed for teams to resolve dependencies collaboratively. The Scrum Master should first engage in problem-solving within the SoS, not bypass it. Immediate escalation without attempting resolution undermines the purpose of the SoS and team empowerment.

Record the dependency on the program board and ask Team Echo to wait until the next PI Planning to renegotiate the feature.

Why it fails: Waiting until the next PI Planning is too late; the dependency is blocking work now. The program board is a visualization tool, not a resolution mechanism. The Scrum Master should act during the ART Sync to help the teams resolve the impediment, not defer it. Deferring also risks missing the PI objectives and erodes trust between teams.

Advise Team Echo to split the feature and deliver the non-authentication portions first while Team Delta continues its current work.

Why it fails: Splitting the feature might be a valid later tactic, but it does not address the fact that Team Delta has not started the authentication service. The immediate problem is the unstarted dependency, not feature decomposition. The Scrum Master should first help Team Delta make the authentication service visible and prioritized, then consider splitting if needed. This option skips the core coordination step.

Escalate to the Release Train Engineer and ask that Team Echo's feature be reassigned to another team that is not blocked.

Why it fails: Escalation may eventually be needed, but the first step is not to reassign work. Reassigning Team Echo's feature ignores the root dependency and may create new knowledge gaps. The Scrum Master's role at the ART Sync is to facilitate resolution within the team network before escalating. Immediate reassignment also undermines Team Delta's accountability for the authentication service they own.

Ignore the uncommitted dependencies and finalize the plan anyway to avoid delaying the PI Planning schedule.

Why it fails: Finalising the plan with uncommitted dependencies conceals risk, so the dependency never reaches the programme board for resolution. Ignoring them is tempting to protect the schedule, but PI Planning explicitly surfaces and addresses cross-ART dependencies; the correct action is to raise them for commitment.

Independently rewrite the other team's backlog items to ensure the required functionality is built locally.

Why it fails: Rewriting another ART's backlog overrides their ownership and planning authority, and the Scrum Master has no mandate to alter another train's items. It is tempting as a way to force local delivery, but cross-ART dependencies are resolved through the programme board and ART sync, not unilateral edits.

Cancel the PI Planning event immediately and postpone it until the other ART finishes their own planning cycle.

Why it fails: Cancelling PI Planning removes the very event where cross-ART dependencies are surfaced and negotiated, and the other ART's cycle timing is not a blocker. Postponement is tempting when dependencies look unresolvable, but dependencies are handled during planning via the programme board, not by abandoning the event.

The Daily Stand-up

Why it fails: The Daily Stand-up is a localized event meant strictly for individual Agile teams to synchronize their daily work and inspect progress toward their iteration goal, lacking the scale required to synchronize an entire release train.

The Scrum of Scrums

Why it fails: The Scrum of Scrums synchronises Scrum teams within a single program, not the entire Agile Release Train; ART Sync is the mechanism that aligns all teams on the train. It is tempting because it is a genuine scaling ceremony, but it operates at the program or team-of-teams level rather than across the full ART.

System Demo

Why it fails: The System Demo shows integrated increment from all teams to stakeholders, but synchronisation of teams' work occurs through the ART Sync event, not the demo. It is tempting because the demo does reveal cross-team integration status, yet it is an inspection and feedback event rather than the primary synchronising mechanism.

Wait until the second day to see if other teams can take over the work.

Why it fails: Delaying the communication of a critical dependency until the second day of PI Planning creates significant risk. It prevents leadership from having the time necessary to adjust the overall plan, potentially leading to a failed planning cycle or unrealistic commitments that the ART cannot actually deliver.

Advise the team to mark the feature as uncommitted without informing management.

Why it fails: Changing a feature to uncommitted without notifying management bypasses the collaborative nature of PI Planning. Leadership needs to understand why certain objectives are at risk to manage stakeholder expectations and ensure that the most valuable work is prioritized and supported by the necessary architectural runway.

Instruct the team to ignore the dependency and plan as if it were resolved.

Why it fails: Planning without acknowledging a known blocker results in an invalid and dishonest plan. This approach undermines the transparency required in SAFe and likely leads to missed commitments during the execution phase, as the underlying technical constraints will eventually halt progress regardless of the initial plan.

Suggest moving the System Demo to every other iteration to allow more time.

Why it fails: Reducing the frequency of the System Demo delays the feedback loop and masks underlying integration problems. SAFe requires a demo every iteration to ensure the ART is actually making progress. Moving the event further apart increases the risk of discovering major architectural or integration flaws too late.

Ask the Product Owner to demo only the features that are fully completed.

Why it fails: While only completed work should be shown, focusing only on isolated features misses the point of the System Demo, which is to show the integrated system. If the teams cannot integrate, the system is not truly functional, and the demo fails to provide a realistic view.

Request that the System Architect takes over the integration responsibilities.

Why it fails: Assigning integration to a single person like the System Architect creates a bottleneck and removes responsibility from the Agile teams. In SAFe, teams are responsible for ensuring their work integrates with the rest of the system, and the Scrum Master should foster this cross-functional accountability.

Estimating new Features using Weighted Shortest Job First (WSJF).

Why it fails: WSJF and feature estimation typically happen during backlog refinement or as part of the preparation for the next PI. While the ART Sync might touch on upcoming work, its primary focus is on the execution and synchronization of the current PI's committed objectives and dependencies.

Conducting individual team retrospectives to improve internal processes.

Why it fails: Individual team retrospectives are private events for the team to improve their own performance. The ART Sync is a higher-level event focused on the coordination across the entire train. Cross-team improvements are handled in the Inspect and Adapt event rather than during the weekly synchronization meetings.

Assigning business value to the newly identified uncommitted objectives.

Why it fails: Business value is assigned by Business Owners during the PI Planning event, specifically during the draft plan review or final plan review. It is not an activity that occurs during the ART Sync, which is focused on synchronization and execution rather than initial value assessment.

Assign the testing tasks to the most experienced developers immediately.

Why it fails: The Scrum Master does not assign tasks. Their role is to facilitate the process of improvement. Furthermore, simply assigning tasks doesn't address the systemic issue of missing automation; the improvement needs to be a planned effort that the whole team commits to during the next PI Planning.

Create a new Feature for 'Automated Testing' and add it to the Funnel.

Why it fails: While automation is important, improvements from the I&A are typically handled as stories or tasks in the Team Backlog or as part of the PI Objectives. Creating a high-level Feature might be too large and could get stuck in the funnel instead of being addressed immediately.

Escalate the issue to the System Architect to solve for the whole ART.

Why it fails: While the System Architect provides guidance, the purpose of the Problem-Solving Workshop is for teams to take ownership of their improvements. Escalating every issue prevents teams from developing their own problem-solving capabilities and may ignore the specific context of how the team's code is structured.

Ask the team to work overtime to ensure all features are included.

Why it fails: Planning for overtime is unsustainable and violates the principle of maintaining a constant pace. It leads to burnout and lower quality work. The purpose of PI Planning is to create a sustainable and predictable plan based on the team's actual historical velocity and current capacity.

Move the excess features to the 'Uncommitted' list without consultation.

Why it fails: The Scrum Master should not unilaterally move features. This decision requires collaboration with the Product Owner to ensure that the most important features remain in the plan. Uncommitted objectives are for items with high uncertainty, not simply for work that exceeds the team's capacity.

Wait for the Draft Plan Review to see if management notices the gap.

Why it fails: Waiting for the Draft Plan Review wastes valuable planning time. The Scrum Master should facilitate immediate problem-solving during the breakout session so the team can present a more mature and realistic draft plan when the review session actually begins later in the day.