Sprint Review and Retrospective

The correct course of action during a Sprint Review when not all features planned in the sprint were completed is to review what was completed, and openly discuss what wasn’t completed and why, to gain insights and feedback. This approach is aligned with the principles of Scrum, encouraging transparency, inspecting the increment, and adapting the plan moving forward. The wrong answers misdirect by suggesting alternative actions that avoid direct discussion of incomplete work during the Sprint Review, suggest premature solutions without sufficient review, or propose changes to the Scrum framework without understanding the specific reasons for incomplete features.

The appropriate approach for a ScrumMaster is to assure the team that the purpose of the experiment is to learn and that failure is an option. This encourages a healthy learning culture within the team where everyone is open to trying out new things. Forcing resistant team members to follow the new approach is not a productive solution, as it does not allow room for open dialogue and it undermines team morale. Ignoring their resistance does not align with the ScrumMaster's role of addressing the team's concerns and ensuring effective communication. Lastly, removing their tasks from the Sprint would be an unnecessary and extreme action that could adversely impact the team's dynamics and productivity.

The correct approach during a Sprint Retrospective after facing blockers would be to encourage a constructive brainstorming session on how to tackle similar problems in future sprints while avoiding any blame game. This choice fosters a solution-oriented and collaborative approach, central to Agile and Scrum methodologies. The aim is to review and adapt in order to improve in the next sprint. This is why the answer 'Encourage a constructive brainstorming session on ways to tackle similar blockers in future sprints and facilitate the process to avoid any finger pointing' is the best answer here.

Ignoring the blockers as past issues ('Ignore the blockers as past issues and focus only on the positives of the completed sprint') is counterproductive as it goes against the principle of inspect and adapt, a key part of Scrum. Assigning blame to specific team members for causing blockers ('Assign blame to specific team members for causing the blockers') works against the principles of teamwork and continuous improvement that Scrum emphasizes. Skipping the retrospective to avoid negative discussions ('Skip the retrospective to avoid negative discussions') neglects a key Scrum ceremony essential for inspecting the work done and adapting the future plan based on the findings, thus it wouldn't be a good idea.