# Sprint Retrospective

**Sprint:** 3
**Date:** 2026-09-22
**Facilitated by:** `scrum-master`, per `process/05_sprint_retrospective.md`
**Inputs used:** `backlog/sprints/sprint-3.md` (Daily Scrum Log + Execution Order), `backlog/backlog.md` (Sprint 3 Review outcome), `code/BENCHMARK.md`, `logs/technical_debt_log.md`, `logs/impediment_log.md`, `backlog/sprints/sprint-2-retrospective.md` (for follow-through check). No live human team to poll in real time this sprint; subjective signals are synthesized from dev-team's own daily-scrum notes and self-reported gaps rather than invented.

## Signals

**Objective:**
- 4/4 committed stories Done (18/18 points), sprint goal assessed "met in full" at Sprint Review (`backlog/backlog.md`, Sprint 3 Review outcome).
- Test suite grew from 195 (Sprint 2 close) to 201 (Day 1) to a final verified 223/223 (Day 2) — the running totals are internally consistent this time (no repeat of Sprint 2's arithmetic slip; see Follow-up below).
- 0 new impediments logged; the two pre-existing open impediments (template path strategy, UNC timeout) remained non-blocking and untouched, as expected.
- Technical debt showed a full loop rather than a one-way accumulation: the High-impact throughput item opened at Sprint 2 close was root-caused, mitigated, and marked **Resolved** this sprint (`logs/technical_debt_log.md`, 2026-09-14 entry) — but the same investigation honestly surfaced and logged a new, narrower Medium-impact item (extrapolated output file size at the 1,000,000-record ceiling, 2026-09-21 entry) instead of declaring the risk fully closed.

**Subjective (from dev-team's daily-scrum notes and epic verification write-ups):**
- Live, actual-built-`.exe` verification (real Win32/UI-Automation input, not an in-process harness) continued for all three GUI-facing CSV stories — direct follow-through on Sprint 2 retro's action item 2, now demonstrated a second time.
- A new, concrete instance of "verify the spec against real code before building": before implementing "Create a dynamic text token," dev-team checked `TEMPLATE_FORMAT.md`/`TemplateXmlParser`/the existing serializer and found the story's own older conversation notes referenced a stale `{{Column Name}}` token format that Sprint 1 had already superseded with a `column="..."` attribute — and built on the real format instead of the stale one, catching this before writing code rather than after.
- Honest gap self-reporting continued: when the sample CSV's `G2 City St ZIP+4` column turned out to be blank in every one of the 392 rows (making the live rebind-render check visually blank), dev-team didn't stop at "technically passed" — it added a second render against a populated column at the same coordinates to get real positive visual proof the pipeline works, and reported the original gap plainly rather than omitting it.
- Product-owner's Sprint 3 review leaned more heavily on dev-team's own pre-written, already-thorough verification notes in `backlog/epics/03_csv_integration_and_field_mapping.md` than in prior sprints, where the epic notes were written fresh at review time. The one story that got a fully independent product-owner pass (the throughput story, which only had a dev-team self-verification note going into review) shows the review step still adds real judgment when exercised — see the Patterns section below.

## What went well
- **Full follow-through on all four Sprint 2 retrospective action items** (see "Follow-up on previous retro's actions" below), including a clean fix of the one process-hygiene watch item named last retro.
- Dependency-ordered batch swarming held for a third consecutive sprint without deviation: the throughput story pulled first (no in-sprint dependency, highest priority), then the CSV chain strictly in dependency order (headers -> token creation -> rebind).
- The throughput story closed a genuine, previously-unknown High-impact risk with real evidence (a completed, non-time-boxed 100k-record run at 315s) rather than a time-boxed approximation — and did so without overclaiming the adjacent 1,000,000-record question as solved.
- "Leave it better than you found it" showed up as **preventive** work this sprint, not just inline fixes: checking the real template format against a stale spec note before coding avoided building a second, wrong persistence format from scratch.

## What didn't go well
- The new Medium-impact file-size debt item (1,000,000-record ceiling) is real, evidence-based, and currently un-owned by any committed story — it needs a decision point before any future story targets rendering near that scale, not urgent for Sprint 4 itself but shouldn't be left to surface unprompted the way the original throughput risk did.
- (Light process note, not a defect) This sprint's product-owner review depended more on dev-team's own pre-written verification narrative for three of four stories than in prior sprints. No AC was actually missed or rubber-stamped incorrectly — the fourth story (throughput) got a fully independent PO pass that added real judgment — but it's worth watching whether epic-note authorship quietly drifts from "PO writes it at review time" toward "dev-team writes it, PO signs it," since that would blur the review step's independence over time.

## Patterns / Insights (prioritized)
1. **(Team-level)** Dependency-ordered swarming plus honest, evidence-first self-reporting are now confirmed strengths across three sprints in a row — stable enough to treat as the default operating mode without re-justifying each sprint.
2. **(Team-level, new this sprint)** "Confirm the real spec/format against current code before building, not just after" is a concrete, repeatable habit worth naming explicitly (the `{{Column Name}}` vs. `column="..."` catch) — distinct from post-hoc verification, and cheaper because it avoids wasted implementation work rather than just catching it late.
3. **(Product-level, not a process/kit matter)** The new 1,000,000-record file-size debt item is this sprint's most consequential open thread — routed to `backlog/backlog.md`'s Sprint 3 Review outcome as a pre-condition for any future large-scale-rendering story, not to a retro action here.
4. **(Process-level, low severity)** The PO-review-independence observation above is real but has not yet caused an actual verification gap — it does not meet the bar for a kit edit (a single, non-severe observation, not a recurring pattern with a demonstrated failure). Logged as a "Watching" entry in `logs/process_improvement_log.md` rather than proposing a change to `process/04_sprint_review.md` on a single instance.

## Kit-level decision
No kit edit proposed this retrospective. The PO-review-independence observation is logged to `logs/process_improvement_log.md` as a first-occurrence "Watching" item per `process/07_process_improvement.md` — it hasn't caused a real defect or missed AC, so it doesn't meet `AGENTS.md`'s bar (recurring pattern of 2+, or one severe occurrence) for editing `process/04_sprint_review.md` or `.claude/agents/product-owner.md`.

## Action Items (added to Sprint 4's plan)
- [ ] Before any future story commits to rendering near the 1,000,000-record ceiling, resolve the open file-size debt item first (count-aware batch sizing or subsetted-font embedding — both candidates already named in `logs/technical_debt_log.md`'s 2026-09-21 entry) — owner: product-owner (prioritization) / dev-team (implementation) — due: before that story is committed, not necessarily Sprint 4.
- [ ] Continue live, actual-built-artifact verification for every GUI-facing story — owner: dev-team — due: ongoing.
- [ ] Continue verifying the real current spec/code (not stale conversation notes or older story text) before implementing, as demonstrated this sprint on the CSV token format — owner: dev-team — due: ongoing.
- [ ] Watch whether product-owner's Sprint 4 review notes are written independently at review time versus carried over from dev-team's own pre-written verification text; no action needed unless it starts producing a missed AC or a rubber-stamped gap — owner: scrum-master — due: Sprint 4 review.

## Deferred / lower-priority ideas (kept, not discarded)
- Whether "Collapse blank optional address lines consistently" (Sprint 4 candidate) needs explicit UX affordance for its own AC4 ("operators can distinguish intentionally blank output from a mapping error") beyond what's already scoped — revisit when that story is actually picked up.
- Whether the CSV rebind combo's fallback behavior (showing an unmatched current column as free text rather than defaulting away from it) needs a visible warning if an operator loads a different CSV with different headers — revisit if this causes real operator confusion, not preemptively.

## Follow-up on previous retro's actions
All four of Sprint 2's retrospective action items were carried into Sprint 3's plan and applied, confirmed via `backlog/sprints/sprint-3.md`'s Notes section and Daily Scrum Log:
1. Prioritize the throughput-degradation story at or near the top of Sprint 3 planning — Applied: pulled first as Batch 1, ahead of the CSV chain.
2. Continue requiring live, actual-built-artifact verification for every GUI-facing story — Applied: all three CSV stories (Batches 2-4) verified against the real built `.exe` with real input injection.
3. Double-check running test-count totals before writing them into the daily scrum log — Applied: this sprint's Day 1 -> Day 2 totals (195 -> 201 -> 223) are internally consistent; the Sprint 2 arithmetic slip did not recur.
4. Continue "leave it better than you found it" and honest gap self-reporting — Applied: the file-size risk was logged honestly rather than glossed over as "solved," and the blank-sample-data gap was called out plus proactively resolved with a second confirming render.

No drops. This is a clean full-follow-through sprint, the second in a row.

## Anti-patterns checked
- **No follow-through on prior retro actions:** Ruled out — all four Sprint 2 actions were applied, not just referenced (see above).
- **Blame-focused discussion:** Ruled out. All findings (the file-size risk, the PO-review-independence note) are described in terms of the system or the process, never an individual.
- **Hidden mini-waterfall within the sprint:** Ruled out. Each batch was designed, built, tested, and live-verified together in one pass, same as Sprints 1-2.
- **Avoiding an obvious known problem:** Ruled out. The new file-size risk directly undercuts a "fully solved" narrative for the throughput story and could have been soft-pedaled given the sprint's other wins — instead it was investigated, quantified, and logged with named follow-up candidates.
- **Status-theater (named explicitly in Sprint 1, improved on in Sprint 2):** Ruled out. Verification evidence this sprint is concrete and checkable (on-disk XML diffs, exit codes, rasterized page crops, exact coordinate matches before/after rebind) rather than narrative claims.