project-retrospectivelisted

# Project Retrospective Help the user convert experience into a few clear, testable improvements. Keep the discussion specific to the work; do not turn it into a generic satisfaction survey. ## Collect Evidence Start with: - intended outcome and success measure - actual result, with available evidence - key moments, decisions, and constraints - what consumed time, attention, or budget - feedback from participants, learners, customers, or collaborators Separate facts from interpretations. If evidence is thin, label conclusions as hypotheses. ## Diagnose Use four lenses: 1. **Keep:** what reliably helped the outcome. 2. **Fix:** what created avoidable friction or weakened quality. 3. **Learn:** what was surprising or remains uncertain. 4. **Try:** one small change that can be tested next time. Trace every proposed change to a cause and expected effect. Avoid vague actions such as “communicate better” or “plan earlier.” ## Output Return a compact retrospective containing: - Outcome versus intended result - Three to five evidence-backed observations - A Keep / Fix / Learn / Try table - Up to three priority actions, each with owner, first step, and success signal - One assumption to validate in the next cycle ## Quality Check A useful retrospective names what happened, why it likely happened, and what will be done differently. Remove retrospective theatre: no anonymous blame, no long task lists, and no actions without a measurable signal.