Introducing Scrum in SAFe practice questions

Require all developers to attend every daily session to provide detailed status updates.

Why it fails: Mandating full developer attendance turns a coordination meeting into a status reporting session. This consumes valuable engineering capacity without adding cross-team value. SAFe emphasizes decentralized decision-making, and individual task tracking should occur within the individual team's daily stand-up, not at the higher-level Scrum of Scrums coordination sync.

Focus the discussion exclusively on individual developer productivity metrics and velocity.

Why it fails: Focusing on individual velocity metrics undermines the team-based approach inherent in Agile. SAFe promotes flow and value delivery rather than individual output. Metrics-driven discussions at the Scrum of Scrums often create defensive environments and distract from the primary goal of resolving systemic dependencies and release-level impediments.

Use the meeting to perform technical code reviews and approve architectural changes.

Why it fails: Performing code reviews during a coordination sync is inefficient and misses the intended scope of the Scrum of Scrums. Technical design and architectural decisions should happen within the System Team or design spikes, not in a synchronization meeting intended for broad team alignment and dependency management.

Assigning tasks to specific developers to ensure individual productivity.

Why it fails: Assigning tasks undermines self-organization. Agile teams should pull work based on priority and capability. When a Scrum Master assigns tasks, they treat team members as cogs in a machine, destroying autonomy and reducing the team's ability to solve problems collectively. This behavior is contrary to building high-performing teams.

Reporting the team's lack of progress to the manager to get people fired.

Why it fails: The Scrum Master should focus on helping the team improve, not on punitive reporting. Threatening team members creates fear and destroys collaboration. The Scrum Master's role is to identify systemic issues and support the team in overcoming them, not to act as a police officer for the organization.

Making all technical decisions to save time during meetings.

Why it fails: Technical decisions should involve the whole team and architects. If a Scrum Master dictates technical decisions, they take ownership away from the developers. This leads to poor outcomes and lack of commitment to the implementation. The Scrum Master should facilitate the discussion, not dictate the technical direction or design.

Product Manager

Why it fails: The Product Manager focuses primarily on the vision, roadmap, and content of the program backlog, rather than the process-oriented synchronization of the team. While they collaborate with teams, they do not hold the primary responsibility for the team's adherence to the Scrum ceremonies or the specific cadence of the ART.

System Architect

Why it fails: The System Architect provides the technical guidance and architectural runway required for the ART. While they are crucial for technical strategy and enabling features, they do not focus on the Scrum process, ceremony facilitation, or the day-to-day synchronization of the team's activities within the established SAFe cadence.

Business Owner

Why it fails: Business Owners are key stakeholders who provide the necessary business context and validate the program's value. Their role is to provide feedback on the solution's performance and align the ART with business goals, not to manage the team's Scrum process, iteration cadences, or internal team coordination mechanisms.

To conduct a root cause analysis of the team's internal process issues.

Why it fails: Root cause analysis is performed during the Iteration Retrospective, not the Review. The Review is focused on the product increment and stakeholder feedback, whereas the Retrospective is dedicated to evaluating the team's processes and finding ways to improve their internal collaboration, workflows, and effectiveness for the next iteration.

To plan the backlog items for the next iteration.

Why it fails: Backlog planning for the next iteration happens during Iteration Planning. The Review is specifically designed to look backward at what was completed in the current iteration and look forward to how that impacts the overall PI goals, rather than performing the tactical work of detailed task-level planning for the future.

To assign performance ratings to team members based on their contributions.

Why it fails: Agile teams are evaluated on their collective output, not individual contributions. The Review is for the product, not personnel management. Using this time for performance reviews would destroy the trust and psychological safety required for a high-performing team and would distract from the goal of delivering high-quality, customer-focused software.

Make the decisions on behalf of the PO to keep the team moving.

Why it fails: A Scrum Master should not take over the PO's responsibility for functional decisions. This risks misalignment with the product vision and business goals. The Scrum Master should facilitate the resolution of the conflict, not become the proxy for the PO, as that creates a bottleneck and obscures the team's needs.

Ask the team to wait until the next PI Planning to ask their questions.

Why it fails: Waiting weeks for critical information is unacceptable in Scrum. It leads to massive amounts of 'work-in-progress' and causes the team to stall. Agile requires rapid feedback loops. Delaying questions would significantly hinder the team's ability to complete their iteration objectives and would result in massive waste and frustration for everyone.

Report the PO to the Business Owner for lack of performance.

Why it fails: Escalating prematurely without a direct conversation is poor leadership. The Scrum Master must first attempt to coach and resolve the issue at the team level. Escalation should only be a last resort if coaching efforts fail, as it damages trust and creates an adversarial environment between team members and leadership.

They are responsible for presenting the entire system to stakeholders.

Why it fails: The Product Manager or System Team typically leads the demo, as they own the holistic view of the solution. The Scrum Master's responsibility is to support the team’s contribution to the demo. Having the Scrum Master present the whole system would be an ineffective use of their coaching and facilitation skills.

They facilitate the demo to ensure it stays on time.

Why it fails: The Release Train Engineer usually facilitates the program-level System Demo, as it involves multiple teams and stakeholders across the ART. The Scrum Master acts as a supporter of the team's demo items, ensuring that the team's work is correctly integrated and that they have the required material to showcase success.

They determine which features from the team are included in the demo.

Why it fails: Feature inclusion is determined by Product Management and the Product Owner based on the program priorities. The Scrum Master does not have the authority to decide what constitutes a feature or which ones are ready for public demonstration; their role is to facilitate the process, not to dictate product content.

The iteration buffer is too low to handle unforeseen technical issues.

Why it fails: While an iteration buffer is good practice, the most critical issue is the length of the planning horizon. A 10% buffer is a common heuristic, but a planning horizon that fails to cover the full PI duration is a systemic failure that breaks the synchronization of the entire ART, causing significant planning gaps.

The team roles are missing a System Architect.

Why it fails: System Architects are ART-level roles, not team-level roles. A Scrum team consists of the Scrum Master, Product Owner, and the development team. The absence of an Architect in the team-level config is standard, not a risk. The planning horizon issue remains the most significant problem identified in the provided configuration policy.

It is an optional iteration that can be used for extra features.

Why it fails: The IP iteration is not optional; it is a mandatory, structural element of the SAFe PI. Using it for feature development defeats its purpose, which is to allow for innovation, technical debt reduction, and planning. Skipping it leads to burnout, lack of improvement, and poor planning for the next PI.

It is used primarily to catch up on missed iteration work.

Why it fails: While it can be used for final PI cleanup, treating it as a 'catch-up' iteration is a sign of poor planning. If teams consistently use the IP iteration to finish work, they are not meeting their commitments, which indicates that the team needs to re-evaluate their planning capacity and estimation accuracy.

It is managed by the Product Manager to update the roadmap.

Why it fails: The IP iteration is for the team and the ART, not just Product Management. While PM updates the roadmap during this time, the primary focus is on team-level innovation, learning, and the ART-level I&A event. Attributing the IP iteration solely to PM work misrepresents its purpose as a dedicated time for the entire ART.

Accept the functional manager approvals as a necessary compliance gate to satisfy corporate governance policies.

Why it fails: Accepting per-story manager approvals preserves the functional silo gate that blocks team-level flow and self-management, directly contradicting SAFe's principle of decentralised decision-making. Such gates suit regulated stage-gate programmes, but here the Scrum Master must instead coach leadership to remove the approval bottleneck.

Bypass the managers entirely by hiding team progress reports and discouraging executive involvement in team decisions.

Why it fails: Hiding progress reports and excluding executives destroys transparency, the core SAFe mechanism for surfacing impediments and securing leadership support. This option would appeal when teams face punitive micromanagement, but the Scrum Master's role is to make the silo and approval bottleneck visible and coach leaders toward ART-aligned flow.

Stop the SAFe launch immediately and revert the enterprise back to waterfall project management methodologies.

Why it fails: Halting the launch prematurely abandons the transformation at the first sign of cultural friction. Organizational resistance is normal when introducing Scrum, and Scrum Masters must guide leaders through the paradigm shift rather than giving up.

A detailed 12-month project timeline.

Why it fails: SAFe focuses on short-term, iterative planning rather than rigid, long-term project timelines. PI Planning covers a single Program Increment, typically 8 to 12 weeks. Detailed planning for 12 months in advance is an anti-pattern that ignores the reality of market changes and feedback loops inherent in Agile.

A finalized, unchangeable backlog.

Why it fails: The backlog in SAFe is dynamic and subject to change based on feedback and learning. A 'finalized and unchangeable' backlog ignores the Agile principle of responding to change. While the plan is committed, the backlog is continuously refined to ensure it delivers the highest value based on new insights.

Make the decisions for the PO to keep the team moving.

Why it fails: The Scrum Master should never take over the PO's responsibilities. Making decisions on behalf of the PO risks creating misalignment with the product vision and can lead to significant rework when the PO finally returns and disagrees with the decisions made by the team or Scrum Master.

Ask the team to pause all work until the PO returns.

Why it fails: Stopping all work is unnecessary and hurts the team's throughput. The team can continue working on well-defined stories or other planned tasks. The Scrum Master's role is to resolve the blocker while ensuring the team maintains as much productivity as possible in the meantime without compromising on quality.

Have the team work on technical debt instead of features.

Why it fails: Working on technical debt is a valid activity but should be planned with the PO. If the PO is unavailable, the team should focus on the most important work already in the backlog. Arbitrarily switching focus to technical debt avoids the core issue of PO unavailability.

Prioritizing the team backlog and accepting completed stories into the baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline

Why it fails: Prioritizing the team backlog and accepting stories is the explicit responsibility of the Product Owner, not the Scrum Master. The Scrum Master ensures the process is running smoothly but avoids making business value decisions on behalf of the Product Owner.

Defining the architectural runway and allocating system architect resources for technical debt.

Why it fails: Defining the architectural runway and managing technical design decisions are responsibilities belonging to System Architects and the Agile Release Train leadership. Scrum Masters support technical health indirectly through impediment removal, not architectural design.

Establishing enterprise portfolio budgets and approving strategic themes for the upcoming fiscal year.

Why it fails: Establishing portfolio budgets and setting strategic themes are executed by Lean Portfolio Management and executive leadership. Scrum Masters operate primarily at the team and program levels, far removed from enterprise-level budgetary approvals.

Assign specific user stories and technical tasks to individual developers based on their specialized skill sets.

Why it fails: Assigning work directly to individuals strips away team self-organization and accountability, violating core agile and SAFe principles. Self-organizing teams must collaboratively pull and own their work items during the planning session.

Rewrite acceptance criteria for all selected user stories to ensure they match the exact formatting required by upper management.

Why it fails: Acceptance criteria are refined collaboratively by the Product Owner and the Agile Team during backlog refinement, not rewritten by the Scrum Master for management. The Scrum Master focuses on facilitation and process health rather than modifying story definitions.

Determine the final economic value and weighted shortest job first ranking for every story brought into the iteration backlog.

Why it fails: Economic prioritization and WSJF ranking are responsibilities of the Product Manager and Product Owner at the program level, not the Scrum Master during team iteration planning. Iteration planning focuses on executing the prioritized backlog provided by the Product Owner.

Scrum replaces all executive oversight with complete team autonomy, eliminating the need for any management reporting or governance.

Why it fails: Scrum does not eliminate governance or management reporting; instead, it replaces bureaucratic status reporting with transparency derived from working software and cadence. Leadership maintains visibility through Program Increment events and system demos.

Agile teams operate in complete isolation from program and portfolio layers, ensuring no outside interference alters their sprint backlogs.

Why it fails: Agile teams do not operate in isolation; they are synchronized to the Agile Release Train cadence and aligned with program objectives and strategic themes. Isolation destroys enterprise alignment and prevents coordinated solution delivery.

Scrum guarantees that every software release will be delivered with zero defects on the exact date predicted during portfolio budgeting.

Why it fails: Scrum and SAFe embrace empirical process control and continuous learning, recognizing that complex software development involves uncertainty. While predictability improves over time, guarantees of zero defects and exact milestone dates are unrealistic.

The development team failed to work sufficient overtime hours to test the software thoroughly before the review meeting.

Why it fails: Overtime hours do not affect whether delivered features address business needs; the failure stems from backlog items not being traced to stakeholder outcomes. It is tempting because extra testing time can improve quality, and would be correct if defects, not misalignment, caused the disappointment.

The Scrum Master failed to enforce strict coding standards and automated testing frameworks across the development team's codebase.

Why it fails: Coding standards and automated testing govern internal code quality, not whether the team built the right features for stakeholders. It is tempting because strong engineering practise supports delivery, and would be correct if the demonstrated functionality were failing due to defects rather than solving the wrong problem.

The stakeholders were not invited to participate in the daily stand-up meetings to review daily progress and code commits.

Why it fails: Daily stand-ups are the team's internal coordination event; stakeholder attendance there does not determine whether backlog items reflect business needs. It is tempting because stakeholder involvement improves transparency, and would be correct if the problem were insufficient visibility rather than misaligned requirements.

Ask the functional manager to continue assigning daily tasks until the team is comfortable with Scrum.

Why it fails: Continuing external task assignment perpetuates the dependency the transition is meant to remove. Scrum teams are self-managing and decide how to turn backlog items into value. A temporary return to managerial assignment would reinforce the old behavior and delay the team's growth. The Scrum Master should instead coach the team and help the manager understand the new accountability boundaries.

Have the Product Owner assign daily tasks since that role already prioritizes the Team Backlog.

Why it fails: The Product Owner owns backlog content and priority, not the team's daily task allocation. Shifting task assignment to the Product Owner still denies the team self-management and muddies two distinct accountabilities. The Scrum Master should coach the team to organize its own work and support the Product Owner in focusing on value and backlog refinement instead.

Assign daily tasks to team members at the end of each stand-up to keep the iteration on track.

Why it fails: Assigning tasks recreates the command-and-control pattern Scrum is meant to replace. The Daily Stand-up exists so the team inspects progress toward the Sprint Goal and re-plans its own work. A Scrum Master who assigns tasks becomes a de facto manager, preventing the team from developing the self-management that Scrum and SAFe both require for reliable, decentralized decision-making at scale.

Mandate that the Product Owner dictates exactly how the team writes their iteration goals.

Why it fails: Dictating iteration goals removes team autonomy and disempowers the Scrum team, which contradicts the core values of Scrum and SAFe. The team must own their goals to ensure high levels of commitment, and top-down mandates often result in lower quality and reduced engagement within the iterative cycle.

Encourage the team to prioritize their own local technical debt tasks over PI objectives.

Why it fails: Prioritizing local technical debt tasks over committed PI objectives undermines the train's predictability and value delivery. While managing technical debt is vital for long-term health, it should be balanced within the capacity allocation defined during PI planning to support the overall system and feature delivery goals.

Advise the team to ignore the PI objectives and focus solely on velocity metrics.

Why it fails: Ignoring PI objectives in favor of velocity metrics is a counterproductive practice that ignores the value-delivery aspect of SAFe. Velocity is a measure of throughput, not business value, and focusing exclusively on it without context often leads to teams delivering work that does not satisfy the ART's mission.

Making all technical decisions for the team to ensure standard compliance.

Why it fails: Scrum Masters do not dictate technical decisions; they facilitate the environment where the team makes their own decisions. Centralizing decision-making hinders team empowerment and slows down the development process, which goes against the principles of self-organization required for teams to operate at scale within SAFe.

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

Why it fails: User stories should be collaboratively defined by the team and the Product Owner to ensure shared understanding and ownership. If the Scrum Master writes all the stories, they diminish the team's understanding of the requirements, which leads to poor quality, misunderstandings, and decreased motivation during the iteration.

Acting as the primary manager of the team members' personal careers.

Why it fails: While Scrum Masters support professional development, they are not the HR managers of team members. Their focus is on team performance, process optimization, and value delivery, not the administrative or career-ladder tasks typically handled by functional managers within the organization's structure, which is separate from the team's delivery.

Increase the frequency of status report meetings for stakeholders.

Why it fails: Increasing status report meetings adds more overhead and administrative burden without addressing the root cause of the impediments. The Scrum Master should minimize distractions that take time away from the team's development work, focusing instead on activities that directly improve the team's ability to deliver working software.

Request that management increase the team's velocity targets.

Why it fails: Arbitrarily increasing velocity targets is a management anti-pattern that ignores the underlying process issues. Velocity is an empirical measure of capacity; forcing an increase without resolving the impediments will only lead to lower quality and team burnout rather than actual improvements in delivered value or goal completion.

Change the team members to improve skill levels.

Why it fails: Changing team members is a drastic measure that does not address the systemic impediments causing the current blockages. The current team likely possesses the necessary skills but is being hampered by external process issues; the Scrum Master should first work to fix the environment before considering personnel changes.

Ask the team to ignore the dependency and hope it resolves itself.

Why it fails: Ignoring a known dependency is a recipe for failure. It masks risks that will inevitably surface during the PI, causing delays and conflicts. Effective SAFe practices require transparency and immediate escalation or negotiation of dependencies to ensure the PI plan remains realistic and achievable for all teams involved.

Inform the Release Train Engineer (RTE) so they can address the dependency.

Why it fails: While the RTE manages the program, the Scrum Master must first facilitate communication between the teams involved. Escalation is a last resort; the teams should attempt to negotiate a solution or identify a workaround first. This fosters collaboration and keeps the decision-making process close to the source of work.

Remove the dependent feature from the team's plan entirely.

Why it fails: Removing a feature without consulting the Product Owner or the ART stakeholders is a unilateral decision that ignores business value. Dependencies must be managed, not simply discarded. The team needs to work with the business owners to understand the impact of any changes to the plan before taking action.