Build a sprint retrospective with business-impact scoring

Retros That Generate Compounding Learning

Most retros produce the same three action items on rotation: communicate better, write more tests, plan more carefully. Atlassian's retrospective guide notes the symptom — recurring abstract action items — and the cause: retros that discuss team dynamics in isolation from business outcomes. The Pragmatic Engineer's writing on engineering productivity argues that high-performing teams tie retro learning to shipped outcomes with explicit impact scoring, not to meeting quality.

How the Build a sprint retrospective with business-impact scoring Prompt Works

The prompt opens with an impact table so the team sees which shipped work moved metrics before any discussion, classifies outcomes so wins and wasted effort are named separately, and requires action items to map to specific observed failure modes. The "trigger that shows it worked" on each action item is the forcing function — generic action items decay; triggered ones get evaluated.

When to Use It

• The same three action items keep appearing in retros.
• The team cannot articulate which shipped work mattered.
• A new PM or EM wants to reset retro discipline.
• Wasted effort is high and the team blames "product" or "engineering."
• Leadership is asking for evidence of learning-from-losses.

Common Pitfalls

• Starting with team feelings. Feelings-first retros never reach root causes. Start with the impact table.
• Generic action items. "Communicate better" is not actionable. Name the specific signal next time will change.
• Not reviewing action items next retro. An action item without a review date decays. Schedule the check.

Sources

• Sprint Retrospectives — Atlassian
• The Pragmatic Engineer Newsletter — Gergely Orosz
• Embracing Agile — Harvard Business Review
• The Power of Small Wins — Harvard Business Review