You may have an X/Y problem. While failure to achieve the Sprint Goal is a problem if it happens often enough, the actual issue you're facing seems to be a lack of trust in the Scrum Team. This is often the result of a lack of process transparency and poor (or at least delayed) ongoing communications with your leadership and/or stakeholders.
The Sprint Review is the wrong Scrum Event to hold this discussion. Regardless of when you hold the discussion, a culture "being held accountable" rather than one of close collaboration and continuous improvement through validated learning will hamper the team's ability to grow and mature.
As the Scrum Master (or whatever your particular agile framework calls your role), you'll need to educate the team, the organization, and the stakeholders on the agile methodology in use, and on the best ways to leverage the agile mechanisms in place to "fail fast" or adapt to unexpected problems. Agility isn't a silver bullet; it just offers more opportunities for adaptation and feedback throughout the development cycle than frameworks based on big, upfront planning.
You may also be missing clear iteration goals or stakeholder collaboration. Alternatively, the team may be suffering from internal or external tasking, rather than outcome-oriented planning and self-organizing behaviors. The team (and the organization) need to solve the underlying process problems, rather than trying to pin blame or transfer responsibility!
Sprint Reviews are not Accountability or Process Improvement Sessions
The Sprint Review is the place to review the work increment. While this can include identifying work not-done, it's not the place to problem-solve for that. The Sprint Review is a reasonable place to discuss problems that were solved, or potential new work that was identified, but it's not the right place to discuss organizational or process impediments. The Scrum Guide says:
The Sprint Review includes the following elements:
- Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
- The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done";
- The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
- The Development Team demonstrates the work that it has "Done" and
answers questions about the Increment;
- The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
- Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
- Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.
Leverage the Sprint Retrospective
The underlying issue here seems to be a lack of transparency and open communications. This is properly the work of a Sprint Retrospective, which provides the Scrum Team opportunities to:
- Inspect how the last Sprint went with regards to people, relationships, process, and tools;
- Identify and order the major items that went well and potential improvements; and,
- Create a plan for implementing improvements to the way the Scrum Team does its work.
At the next Sprint Retrospective, the team should ask themselves:
Why were our estimates off this Sprint?
- Was there anything we should have done differently?
- What can the team can do differently next time?
Why wasn't at-risk work flagged/escalated/communicated earlier in the Sprint?
- Was the Sprint Goal at risk? If so, why didn't the Product Owner know before the Sprint Review?
- If the Product Owner knew, why weren't the stakeholders informed?
- If the team knew the Sprint could meet its goals, why didn't the Product Owner work with the team to remove scope, or call for an early termination?
Why isn't the team engaging senior management or stakeholders when problems arise?
- Why aren't the Scrum Master and/or Product Owner routinely engaged with the Development Manager and Director?
- Why isn't the Development Team routinely engaged with users or stakeholders throughout the development process?
Why is the daily standup, Kanban board, burndown chart, or other meetings and artifacts not telegraphing blockers or schedule/delivery risk earlier in the process?
- Why are blockers and risks not being raised at the daily standup sooner in the process?
- Why doesn't the team feel incentivized to communicate honestly about schedule risks?
The goal of a Sprint Retrospective is process improvement. As the process referee, the Scrum Master must ensure that the team focuses on root cause analysis and actionable process changes, rather than allowing the event to devolve into blaming, kvetching, or hand-waving.
Identify Your Iteration Goals
In Scrum, you must always have a central coherency to provide focus to the Sprint. You can then use the Sprint Goal to focus the team's energy and capacity on the right things. If you're following some other agile methodology, then you still need to find a way to help the team focus on rapid mini-iterations towards the Definition of Done, rather than on just "completing lots of things."
The lack of an overarching goal often drives incomplete iterations, because team members are focused on getting their individual tasks done rather than on completing the gestalt planned for the iteration. This is quite common in organizations that are new to agile principles, or that haven't fully adopted (or mastered) a given agile framework.
In Scrum-like environments, questions like "Why didn't you complete all the things?" is generally code for "We're setting management targets for individual utilization rather than team objectives for each iteration." Real agility comes from systems thinking, self-organizing teams, and continuous process improvement. While mis-estimation crops up frequently in agile implementations, command-and-control tasking and externally-imposed plans are much more likely to be the real problem.
Ensuring that the team has clear iteration goals, and that the team's artifacts and events reflect daily progress towards (or away from) successful completion of those goals, is the essence of agility. If you lack a clear goal, or if the team doesn't evaluate its progress against that goal every single day, most of the benefits of agility will be lost.