Supporting Team Events practice questions

Require all team members to submit written status reports to management one hour prior to the meeting.

Why it fails: Mandating written status reports increases administrative burden and reinforces a command-and-control culture. SAFe promotes decentralized decision-making and self-organizing teams, meaning status should be communicated verbally and transparently within the team during their synchronized daily events.

Facilitate the meeting by asking each member what they did yesterday, what they will do today, and what impediments they have.

Why it fails: Strictly adhering to individual status questions often turns the event into a boring routine where members talk only to the Scrum Master. Teams should focus collectively on reviewing the iteration backlog board and discussing progress toward the iteration goals instead.

Extend the duration of the Daily Stand-up to 45 minutes to allow for deep technical problem-solving.

Why it fails: Extending the Daily Stand-up beyond the strict 15-minute timebox reduces team productivity and leads to participant fatigue. Detailed technical problem-solving should be deferred to a separate breakout discussion involving only the specific individuals needed for that specific issue.

Allow the loudest senior engineer to dictate the final story point value to save valuable time.

Why it fails: Allowing senior engineers to dictate estimates silences junior team members and destroys collective team ownership. Estimates must be a collaborative team consensus to ensure everyone understands the work and commits to the final iteration plan.

Enforce a strict rule that all stories must automatically be estimated at exactly 5 points.

Why it fails: Arbitrarily assigning the same point value to every story destroys the statistical value of velocity and invalidates planning metrics. Story points must genuinely reflect relative size, uncertainty, and effort for each unique user story in the backlog.

Update the Definition of Done to be more lenient so the team can mark work as complete.

Why it fails: Weakening the Definition of Done creates technical debt and lowers overall quality. The goal of an Agile team is to build higher-quality software over time, not to hide deficiencies by lowering standards. The team should focus on improving their processes to meet the established, high-quality definition of done.

Ask the developers to work overtime to complete the unfinished features before the next demo.

Why it fails: Sustainable pace is a fundamental Agile principle. Forcing overtime leads to burnout and a decline in code quality, which is counterproductive to long-term success. The focus should always be on identifying process bottlenecks and improving team efficiency through better planning and collaboration rather than relying on unsustainable human effort.

Instruct the team to ignore the DoD for this iteration and focus on the next PI's goals.

Why it fails: Ignoring the Definition of Done undermines the team's integrity and quality standards. If the team skips quality gates, technical debt accumulates, making future work significantly harder and more error-prone. The Scrum Master must protect the team's standards to ensure long-term stability and success for the entire organization.

Have the team estimate all stories in the product backlog to ensure future planning is easier.

Why it fails: Estimating the entire product backlog is a massive waste of time, as priorities change and requirements evolve. The team should focus their estimation efforts only on the items relevant to the current or upcoming iterations to ensure they are working on current needs and maintaining high productivity.

Assign specific tasks to individual team members to ensure everyone has an equal workload.

Why it fails: Agile teams are self-organizing and should choose their tasks, not have them assigned. Assignment kills autonomy and ownership, which are essential for high-performing teams. The Scrum Master should foster a culture where individuals volunteer for work based on their skills, interests, and the overall needs of the iteration.

A detailed technical report on every bug found during the iteration.

Why it fails: The Retrospective is about process and team dynamics, not detailed bug reporting. If every bug were reviewed in detail, the meeting would take hours and lose focus on the systemic issues that cause bugs in the first place. This data should be handled during regular team synchronization or development meetings.

A list of individual performance reviews to be shared with the team's manager.

Why it fails: The Retrospective must remain a safe, blame-free environment. Including performance reviews would immediately destroy the psychological safety required for honest communication. Performance management is a separate management function that should never be conducted during a team-level retrospective, as it would cause team members to hide their true challenges.

Select the stories for the team to ensure they pick the most technical ones.

Why it fails: The team should self-organize and select the stories based on the priority set by the Product Owner. A Scrum Master selecting stories for the team undermines their autonomy and decision-making capability. The team must own the plan to be truly committed to executing it effectively and with quality.

Write the user stories to ensure they are technically accurate.

Why it fails: The Product Owner is responsible for the backlog and writing user stories. The Scrum Master's role is to coach the Product Owner on writing good stories, not to write them. Doing so blurs the roles and prevents the Product Owner from effectively managing the backlog and business value.

Mark the feature as complete to avoid impacting the team's velocity metrics.

Why it fails: Inflating velocity with incomplete work creates a false sense of capacity. This practice masks underlying process issues and prevents the team from identifying true throughput, which ultimately leads to poor planning and unreliable commitments in future iterations, damaging stakeholder trust and transparency.

Demonstrate the feature anyway to show stakeholders the progress made so far.

Why it fails: Demonstrating incomplete work confuses stakeholders regarding the actual state of the increment. It undermines the Definition of Done and obscures the fact that the work is not yet releasable, which complicates the feedback process during the review event.

Ask the stakeholders to approve the feature as it is so the team can move forward.

Why it fails: Stakeholders should not override the Definition of Done. Quality standards are internal team agreements that ensure technical excellence. Seeking approval for incomplete work compromises the integrity of the product and sets a poor precedent for future development cycles.

Ensure the team focuses on identifying individuals responsible for iteration failures.

Why it fails: Retrospectives must focus on systems and processes, not individuals. Blaming team members creates a defensive culture, shuts down honest communication, and prevents the group from finding the real root causes of performance issues, which is counterproductive to team growth.

Allow the Product Owner to dictate which processes the team must change.

Why it fails: Process changes must be owned by the team to be effective. When an external stakeholder dictates how the team should work, it reduces autonomy and decreases team buy-in. The team is best positioned to determine which process adjustments will yield the best results.

Require the team to document every minor issue discussed during the session.

Why it fails: Over-documenting every detail turns the retrospective into a bureaucratic chore rather than a constructive session. It loses the focus on actionable outcomes and makes the team feel burdened by the process rather than empowered by it, which reduces overall engagement.

Assigning specific tasks to individual team members to ensure accountability.

Why it fails: In Agile teams, work is pulled, not assigned. Managers or Scrum Masters assigning tasks removes team autonomy and discourages collective ownership. The team should self-organize to determine how they will fulfill the plan, which promotes accountability through peer commitment instead.

Writing the user stories for the team based on the Product Owner's vision.

Why it fails: The Product Owner is responsible for the product backlog and defining user stories. The Scrum Master should coach the team on how to refine stories, but writing them is not the Scrum Master's responsibility, as this could lead to a lack of understanding.

Accept the story into the iteration backlog and schedule a mid-iteration refinement session to write the acceptance criteria.

Why it fails: Accepting unrefined stories directly into the iteration compromises the predictability of team flow and creates significant delivery uncertainty. Refinement must happen prior to planning rather than waiting until the iteration has already started to define the scope.

Advise the team to split the story immediately during planning and estimate the first smaller piece while discarding the rest.

Why it fails: Splitting stories on the fly during planning lacks necessary collaboration with stakeholders and technical staff, often resulting in poor slicing. Slicing should occur collaboratively during backlog refinement sessions ahead of the formal planning event.

Assign the story to a senior developer to write the acceptance criteria and break it down independently after planning concludes.

Why it fails: Product backlog items are owned by the Product Owner in collaboration with the entire Agile Team, not assigned to individuals in silos. Individual assignment undermines team collaboration and bypasses the collective ownership required in SAFe.

Require all team members to address their detailed status reports exclusively to the Product Owner.

Why it fails: Directing status reports to the Product Owner maintains the anti-pattern of upward reporting. The Daily Stand-up must remain a peer-to-peer synchronization meeting focused entirely on meeting the current iteration goals, rather than an administrative status briefing.

Replace the daily sync with an asynchronous chat channel to eliminate meetings entirely.

Why it fails: Replacing synchronous daily alignment with chat channels removes vital real-time collaboration. While asynchronous communication supports distributed teams, it cannot fully replicate the rapid problem-solving and high-bandwidth synchronization of a daily stand-up.

Attend the meeting silently only when invited, refusing to speak or facilitate under any circumstances.

Why it fails: Abandoning facilitation duties entirely leaves immature teams without guidance to fix broken processes. The Scrum Master must actively coach the team toward healthy collaboration patterns rather than completely withdrawing from the ceremony.

Record the dependency on the program board and escalate it at the next Scrum of Scrums or ART Sync.

Why it fails: Recording and escalating at the next Scrum of Scrums is appropriate for tracking, but it is not the immediate action to resolve the blocker. The team remains blocked until the dependency is addressed. The Scrum Master should first attempt to remove the impediment directly, using the program board as a tool if needed, but immediate action takes precedence over waiting for a scheduled event.

Instruct the team member to work on a different backlog item until the other team delivers the API.

Why it fails: Simply redirecting the team member may mask the impediment and delay resolution. The Scrum Master is responsible for removing blockers, not just working around them. While the team member may eventually need to switch tasks, the Scrum Master should actively pursue resolution of the dependency, such as contacting the other team's Scrum Master or facilitating a conversation between the teams.

Ask the Product Owner to reprioritize the backlog so the blocked item is moved to the next Iteration.

Why it fails: Reprioritizing the backlog is a Product Owner responsibility, but moving the item does not remove the impediment; it merely defers it. The Scrum Master should focus on resolving the current blocker to keep the team productive. Involving the Product Owner may be necessary later, but the immediate action is to address the dependency directly with the other team's Scrum Master or the RTE.

Ignore the dependency and assume the supplier will magically deliver on time.

Why it fails: Ignoring dependencies introduces severe risks to the Agile Release Train and undermines the integrity of PI objectives. Teams must proactively address risks rather than hoping external suppliers will somehow miraculously meet uncommitted deadlines without prior communication or formal agreement.

Have the team commit to the original plan and blame the supplier if failure occurs later.

Why it fails: Blaming external suppliers fosters a toxic cross-organizational culture and violates SAFe principles of shared responsibility. Teams should focus on collaborative problem-solving and proactive risk mitigation instead of assigning fault after a failure has already impacted the release train.

Cancel the PI Planning event immediately until the supplier signs a legally binding contract.

Why it fails: Canceling PI Planning halts the entire Agile Release Train and disrupts cadence, which contradicts fundamental SAFe synchronization rhythms. Complex dependencies should be managed through programmatic coordination mechanisms like ROAMing risks rather than stopping vital planning ceremonies completely.

Impose a mandatory strict coding standard without consulting the development team members.

Why it fails: Imposing top-down coding standards violates SAFe principles of self-organization and psychological safety within Agile teams. Improvements must be collaboratively identified and agreed upon by the team during the retrospective to ensure genuine ownership and long-term compliance.

Escalate the developers to upper management for poor code quality and demand disciplinary actions.

Why it fails: Escalating team members for disciplinary actions destroys psychological safety and prevents open communication during retrospectives. Scrum Masters must foster a blame-free culture where technical debt is treated as a systemic process challenge rather than an individual failure.

Cancel all future retrospectives and reallocate that time strictly to writing more user stories.

Why it fails: Cancelling retrospectives removes the team's inspect-and-adapt mechanism and does not address the technical debt root cause. It is tempting because writing more stories appears to increase delivery, but the Scrum Master's role is to facilitate the retrospective and help the team create improvement actions.

Bar the dissatisfied stakeholder from attending future Iteration Review meetings to avoid negative feedback.

Why it fails: Excluding the stakeholder removes the feedback channel that surfaces requirement misunderstandings, so the mismatch would persist unnoticed. Barring attendance is tempting because negative feedback feels disruptive, but the Iteration Review exists precisely to inspect the increment and adapt; the correct response is to improve collaboration and acceptance-criteria refinement.

Rewrite all future acceptance criteria yourself to ensure stakeholders never complain again.

Why it fails: The Scrum Master owns no requirement authorship; rewriting criteria unilaterally removes the Product Owner's accountability and the team's shared understanding. It is tempting because tighter criteria appear to close the feedback gap, but the real fix is involving the stakeholder in refining acceptance criteria during backlog refinement.

File a formal complaint against the stakeholder with the Agile Program Management Office.

Why it fails: Escalating to the APMO addresses governance, not the underlying gap: acceptance criteria were written without the stakeholder validating them. It is tempting because formal escalation exists for persistent stakeholder misconduct, yet here the failure is requirements elicitation, which the Scrum Master resolves through collaboration, not complaints.

The team took an unauthorized vacation for the remaining two days of the iteration.

Why it fails: Taking unauthorised leave misrepresents the situation and implies misconduct where none exists. The team legitimately completed its Sprint Backlog commitment. This explanation would fit only if the team genuinely absented itself without agreement, which the stem does not describe.

The Scrum Master forbade the team from doing any work once the initial stories were completed.

Why it fails: The Scrum Master has no authority to forbid work; that contradicts self-management and servant-leadership. The team's choice reflects their own judgement about Sprint Goal integrity. A Scrum Master would intervene this way only if the team were violating Scrum rules, not for finishing early.

The team should have pulled in 20 more user stories immediately without refinement.

Why it fails: Pulling in unrefined stories mid-iteration bypasses the team's Definition of Ready and Sprint Backlog commitment, risking scope creep and unvalidated work. Adding scope is legitimate only when the Product Owner negotiates it and the team confirms capacity, not as an automatic response to early completion.

Implement a strict rule that no new work can be added after the planning session.

Why it fails: Absolute bans on scope change can be counterproductive in a flexible Agile environment. The team should instead work with the Product Owner to establish a process for handling urgent requests, ensuring that any new work does not compromise the overall iteration commitment or create unnecessary context switching for developers.

Enforce a timebox of 15 minutes for the Daily Stand-up and cut off any long discussions.

Why it fails: While keeping the Daily Stand-up under 15 minutes is a best practice, simply enforcing the timebox does not address the underlying delivery issues. The team needs to understand why the meetings are long and focus on solving the systemic bottlenecks that are preventing their efficient progress and delivery.

Ask the team to move testing tasks to the start of the iteration to avoid delays.

Why it fails: Moving tasks without addressing the root cause, such as the mid-iteration requests, will likely lead to similar delays. The team must optimize their entire workflow to ensure that testing is integrated continuously, rather than just shifting the order of tasks without resolving the underlying interruptions to their work.

Act as the primary speaker to ensure all status updates are delivered quickly.

Why it fails: When the Scrum Master leads the status updates, the team loses accountability and becomes passive observers rather than active participants. The team must own their progress and challenges, and the Scrum Master should focus on facilitating the conversation, not dictating the content or managing the status for the individuals.

Require each team member to provide a detailed report on every task they worked on yesterday.

Why it fails: Detailed reporting creates a culture of micromanagement and wastes time. The focus should be on the team's progress toward the goal, not a granular accounting of every task. Excessive detail in meetings often bores participants and obscures the most important information, which is whether the team will succeed.

Direct the discussion to only the technical architecture of the upcoming user stories.

Why it fails: While technical architecture is important, the Team Sync is meant for broad alignment and blocker removal. Focusing exclusively on architecture ignores other critical aspects of the iteration, such as testing, dependencies, and business value delivery, which are essential for the team to achieve their commitments within the iteration.

Choose the most important collaboration improvement for the team and assign it as an objective.

Why it fails: Assigning improvements removes team agency and ownership. The Scrum Master should act as a coach, not a manager, allowing the team to discover which improvements will work best for their unique dynamics. When a team selects their own focus, they are far more likely to successfully implement the change.

Provide the team with a list of proven collaboration techniques to implement immediately.

Why it fails: While offering suggestions is helpful, forcing a top-down list of techniques ignores the specific context of the team. The Scrum Master should help the team reflect on their own experiences to find a solution that fits their environment, rather than imposing external best practices that might not be suitable.

Document the team's concerns but wait for management to provide a solution.

Why it fails: Waiting for management to solve team-level problems defeats the purpose of an Agile team. The team is empowered to manage their own process and solve their own issues. The Scrum Master must help the team realize their own power to make changes rather than relying on external intervention from management.

Call out the team member in front of the team to ensure accountability.

Why it fails: Publicly calling out team members creates a culture of fear and damages psychological safety. The Scrum Master should lead with empathy and work to understand the root cause of the behavior privately, ensuring that the team remains a safe environment where individuals feel comfortable communicating challenges or issues.

Ask the Product Owner to remove the team member from the project for lack of commitment.

Why it fails: Removing a team member is an extreme measure that ignores the potential to coach and improve team behavior. The Scrum Master's role is to facilitate growth and resolution, not to advocate for personnel changes unless there is an clear and persistent issue that cannot be resolved through coaching.

Ignore the behavior if the team member completes their assigned tasks on time.

Why it fails: Individual performance is only one aspect of success; team synchronization is equally critical in Agile. If a member is absent, the team loses valuable information that could lead to faster delivery or early risk identification. The Scrum Master must ensure that all team members are engaged in collective synchronization.