Sprint Review & Product Retrospective

An effective Sprint Review serves two distinct purposes: demonstrating completed work and gathering feedback. Common mistakes that undermine both purposes: (1) Showing slides about what was built instead of demonstrating the actual product — slides are sales presentations; reviews require live product demonstrations. If it can't be shown live, explain why and show the closest available artifact. (2) Skipping stakeholder questions to stick to a tight schedule — the most valuable outputs of a review are the questions and reactions from stakeholders who were not in day-to-day sprinting. Budget time for discussion. (3) Reviewing only "done" work and skipping items that were not completed — this creates the misleading impression that scope was fully achieved and removes learning opportunities from partial completions. (4) Inviting too broad an audience — a 40-person Sprint Review becomes a performance rather than a feedback session. Keep the audience to team members, product leadership, key stakeholders, and customer-facing representatives (one or two CSMs or Support Ops leads). Product Ops designs the review format, prepares the agenda, and ensures demonstrations show user-facing value rather than technical implementation detail.

The retrospective is the team's highest-leverage improvement tool — a well-facilitated 60-minute retrospective produces specific, actionable improvements that compound over time. Facilitation structure: (1) Data — start with facts: what did we ship? What were our velocity and quality metrics? What were the highlights and the drag-down events of the sprint? (2) Feelings — "what made this sprint energizing or frustrating?" — allow the team to express the emotional reality of the sprint, not just the metrics. Psychological safety requires that "frustrating" is as welcome as "energizing." (3) Insights — what patterns does the data + feelings reveal? What systemic issues are surfacing repeatedly? (4) Actions — convert insights to specific, owned action items. "We should communicate better" is not an action item. "Sarah will add a 5-minute async standup summary every Wednesday to reduce misalignment, starting next sprint" is an action item. (5) Agreements — close by reviewing the action items from the previous retrospective: were they completed? What was the result? This accountability transforms the retrospective from a venting session into a genuine improvement engine.

Sprint retrospective data is richest when aggregated across teams over time — patterns visible across multiple squads reveal systemic process issues that no individual team retrospective can diagnose. Product Ops maintains a retrospective theme database: after each sprint cycle, the common themes from all squad retrospectives are tagged and entered into a shared record. Over 4–6 sprints, patterns emerge: "three squads are independently reporting that QA handoffs at the end of sprints create weekend work pressure." This is a systemic process problem that one team's action items cannot solve — it requires a cross-team process change facilitated by Product Ops. Product Ops aggregates these patterns into a quarterly "Process Health Report" presented to engineering and product leadership: the top 5 recurring process pain points across all teams, with the proposed systemic fix for each. This distinguishes efficient, high-impact Product Ops from retrospective-checkbox-filling.