Project Review and Retrospective Checklist

Pull the original charter or PRD and the closed Jira/Linear epic. List every committed deliverable next to what actually shipped, what was descoped, and what slipped to a follow-up epic. Note carry-over tickets so they don't get lost in the next sprint planning.

For each user story, verify the PM has marked acceptance criteria met in the ticket. Stories closed without explicit AC sign-off are a common audit finding under SOC 2 change management — the deliverable shipped but the trail is missing.

Use a structured format — Mad/Sad/Glad, Start/Stop/Continue, or 4Ls — in a Miro or FigJam board. Keep it blameless: focus on systems and processes, not individuals. Time-box to 20 minutes of silent generation, 15 minutes of grouping.

Pull PagerDuty/Opsgenie incident counts, after-hours pages, and MTTR for the project window. A spike in pages tied to project commits is a signal the rollout strategy or test coverage needs work for the next phase.

Look at story points completed per engineer and PR review load distribution. One engineer doing 60% of reviews or carrying every gnarly migration is a bus-factor risk. CODEOWNERS should spread review load; if it isn't, fix it before the next epic.

Capture deployment frequency, lead time for changes, change failure rate, and MTTR from your CI/CD platform (GitHub Actions, CircleCI, Jenkins) and incident system. Compare to the previous project's baseline — directional movement matters more than absolute numbers.

Common patterns: PRs sitting more than 24 hours waiting on review, refinement that fails to close out tickets as ready, standup running past 15 minutes, sprint goals carried over three sprints in a row. Name the bottleneck with a metric, not a vibe.

For each new service or major surface introduced, confirm a runbook exists in Confluence/Notion/Backstage and the architecture diagram is current. Missing runbooks become 3am pages with no on-call playbook — the most common SEV-escalation cause for new services.

Compare coverage delta on changed files to the team's threshold (commonly 80%). Pull SonarQube or Code Climate's new code smells, cognitive complexity hot spots, and duplications introduced during the project.

Filter Jira/Linear for bugs labeled with the project's epic or fix-version. Decide for each: fix in the next sprint, accept and document, or close. Don't let a 40-bug backlog become invisible by burying it behind a stale label.

Pull the CI flake rate per test file from the last 30 days. Tests with under-90% pass rate erode the team's faith in red builds and become the gateway drug to merging through failed CI. Quarantine or delete them; don't tolerate.

List every SEV1 and SEV2 in the project window from incident.io / FireHydrant / PagerDuty. For each, link the contributing commit or release. Patterns — same service paged three times, same root cause across incidents — are the signal worth chasing.

Verify every SEV1/SEV2 has a published blameless PIR with named action items tracked in Jira/Linear. PIRs whose action items aged past 60 days are the ones that lead to the next outage with the same root cause.

List flags created for the launch in LaunchDarkly / Unleash / Statsig. For each, decide: keep (with named owner and review date), remove now, or schedule cleanup ticket. Stale flags compound — quarterly cleanup is much cheaper than annual.

Compare adoption, activation, p95 latency, error rate, and any project-specific KPIs (conversion lift, support-ticket reduction) against the baseline captured at kickoff. If baseline wasn't captured, document that gap as an action item for next project's kickoff checklist.

Ask support for ticket volume tagged to the new feature, top three confusion points, and any recurring NPS comments. CSMs often have qualitative signal that doesn't show up in product analytics — bug reports phrased as feature requests, friction in onboarding flows.

Five-question Slack poll or Google Form to PM, design, support, sales: Was the launch timing predictable? Did you have what you needed? Was the changelog and demo enough? Cross-functional misalignment usually surfaces here, not in the engineering retro.

If the project produced SEV1/SEV2 incidents, hold a separate 60-minute deep-dive with the on-call rotation, IC, and service owner before the broader retro action-item meeting. Surface contributing factors that the retro alone won't catch — alert tuning, missing dashboards, deployment automation gaps.

Every action item needs a named owner, a target sprint, and a definition of done. Items without owners die on the retro board. Tag with a consistent label (e.g., retro-action) so they can be tracked across sprints.

Post a short Confluence/Notion page and #engineering Slack thread covering: outcomes, top three what-went-wells, top three improvements, action items with owners. Keep it under one screen — long retro write-ups don't get read.

Put a 30-minute recurring review on the calendar with the EM and tech lead to walk action items. Anything still open at 60 days either gets re-scoped, owner-changed, or closed with a documented decision — drift is the failure mode.