project-management
Sprint Retrospective
Run effective sprint retrospectives that produce actionable improvements — with facilitation formats, data gathering techniques, and experiment-based follow-through.
retrospectiveagilesprintcontinuous-improvementfacilitation
Works well with agents
Works well with skills
sprint-retrospective/
q1-sprint-12.md
Markdown| 1 | # Sprint Retrospective: Sprint 12 |
| 2 | |
| 3 | - **Sprint dates**: February 24 – March 7, 2026 |
| 4 | - **Team**: Payments squad — @alex (tech lead), @maria, @chris, @priya, @lin |
| 5 | - **Facilitator**: @maria |
| 6 | - **Format**: Start/Stop/Continue |
| 7 | - **Sprint goal**: "Merchants can process refunds through the dashboard without contacting support" |
| 8 | - **Goal status**: Partially met — refund processing works, but the confirmation email is not yet sending |
| 9 | |
| 10 | --- |
| 11 | |
| 12 | ## Previous Action Items Review |
| 13 | |
| 14 | | Action Item | Owner | Status | Result | |
| 15 | |------------|-------|--------|--------| |
| 16 | | Add deploy smoke tests for payments service | @chris | Completed | Smoke tests caught a breaking config change in this sprint — prevented a production incident | |
| 17 | | Document the settlement reconciliation process | @alex | In Progress | Draft written, pending review from finance team | |
| 18 | | Reduce staging environment spin-up time from 12 min to under 5 min | @lin | Not Started | Deprioritized due to refund feature deadline pressure | |
| 19 | |
| 20 | **Note**: 1 of 3 items completed. The team discussed whether this indicates overcommitment. Consensus: the staging spin-up item was knowingly deprioritized for the sprint goal, which is acceptable. The documentation item needs a deadline. |
| 21 | |
| 22 | --- |
| 23 | |
| 24 | ## Data Gathering |
| 25 | |
| 26 | ### Start |
| 27 | |
| 28 | - Start pairing on complex database migration work — @maria and @chris both spent time debugging the same refund state machine issue independently before realizing it |
| 29 | - Start writing ADRs for payment flow decisions — we made 3 architectural choices this sprint with no written rationale |
| 30 | - Start including QA in sprint planning — @priya found acceptance criteria gaps on day 3 that could have been caught in planning |
| 31 | |
| 32 | ### Stop |
| 33 | |
| 34 | - Stop deploying after 3pm on Fridays — the refund endpoint deploy at 4:15pm last Friday caused an alert at 5:30pm that @alex had to handle over the weekend |
| 35 | - Stop carrying incomplete stories across sprints without re-estimating — the refund email story was "almost done" for 2 sprints and kept getting underestimated |
| 36 | - Stop using Slack DMs for technical decisions — @lin discovered on day 6 that @alex and @chris had agreed on a refund state model in DMs that contradicted the ticket |
| 37 | |
| 38 | ### Continue |
| 39 | |
| 40 | - Continue the 15-minute deploy verification step after each release — caught 2 issues this sprint before users were affected |
| 41 | - Continue daily async standups in the team channel — worked well for the 3 days @priya was in a different timezone |
| 42 | - Continue dedicating 20% of capacity to tech debt — the Redis connection pooling fix from tech debt allocation eliminated the intermittent timeout errors |
| 43 | |
| 44 | --- |
| 45 | |
| 46 | ## Themes |
| 47 | |
| 48 | **Theme 1: Knowledge silos and invisible decisions (7 votes)** |
| 49 | Three technical decisions were made in DMs or ad-hoc calls without documentation. Two engineers duplicated debugging effort. Information is not flowing to the full team. |
| 50 | |
| 51 | **Theme 2: Late-sprint deploys creating weekend pressure (5 votes)** |
| 52 | Two of the last three sprints had Friday afternoon deploys that generated off-hours alerts. The team feels pressure to ship before sprint end, leading to risky timing. |
| 53 | |
| 54 | **Theme 3: QA involvement too late (4 votes)** |
| 55 | Acceptance criteria gaps discovered mid-sprint cost an estimated 1.5 days of rework on the refund flow. Earlier QA input would have caught ambiguities. |
| 56 | |
| 57 | --- |
| 58 | |
| 59 | ## Experiments |
| 60 | |
| 61 | ### Experiment 1: Channel-first decisions |
| 62 | |
| 63 | **Theme**: Knowledge silos and invisible decisions |
| 64 | **Hypothesis**: If we post all technical decisions to #payments-decisions (even small ones) before implementing, then the team will have shared context and reduce duplicate work, measured by zero instances of "I didn't know we decided that" in the next sprint. |
| 65 | **Experiment**: Any technical decision — API shape, state model, library choice — gets a 2-3 sentence post in #payments-decisions before code is written. Reactions count as acknowledgment. |
| 66 | **Owner**: @alex |
| 67 | **Duration**: 2 sprints |
| 68 | **Success criteria**: Zero surprises in sprint 13 and 14 standups; the team can describe current architectural decisions without checking DMs. |
| 69 | |
| 70 | ### Experiment 2: Deploy freeze after 2pm Friday |
| 71 | |
| 72 | **Theme**: Late-sprint deploys creating weekend pressure |
| 73 | **Hypothesis**: If we institute a Friday 2pm deploy cutoff, then weekend on-call alerts from fresh deploys will drop to zero, measured by PagerDuty incident count on Saturdays. |
| 74 | **Experiment**: No production deploys after 2pm Friday. If a story isn't deployed by 2pm, it carries to Monday. CI/CD pipeline will post a reminder at 1pm. |
| 75 | **Owner**: @lin |
| 76 | **Duration**: 2 sprints |
| 77 | **Success criteria**: Zero weekend PagerDuty incidents caused by same-day deploys in sprints 13 and 14. |
| 78 | |
| 79 | ### Experiment 3: QA review of acceptance criteria in refinement |
| 80 | |
| 81 | **Theme**: QA involvement too late |
| 82 | **Hypothesis**: If @priya reviews acceptance criteria during backlog refinement (2 days before planning), then mid-sprint AC rework will decrease, measured by tracking rework hours. |
| 83 | **Experiment**: @priya attends Wednesday refinement sessions and flags ambiguous or untestable acceptance criteria before stories enter the sprint. |
| 84 | **Owner**: @priya |
| 85 | **Duration**: 2 sprints |
| 86 | **Success criteria**: Zero stories require acceptance criteria changes after sprint planning in sprints 13 and 14. |
| 87 | |
| 88 | --- |
| 89 | |
| 90 | ## Action Items Carried Forward |
| 91 | |
| 92 | | Action Item | Owner | Deadline | |
| 93 | |------------|-------|----------| |
| 94 | | Complete settlement reconciliation documentation | @alex | March 14, 2026 | |
| 95 | | Reduce staging spin-up time to under 5 min | @lin | March 28, 2026 | |
| 96 |