# Sprint Retrospective

**Sprint:** 1
**Date:** 2026-09-11
**Facilitated by:** `scrum-master`, per `process/05_sprint_retrospective.md`
**Inputs used:** `backlog/sprints/sprint-1.md` (Daily Scrum Log + Sprint Review Outcome), `logs/technical_debt_log.md`, `logs/impediment_log.md`, `logs/process_improvement_log.md`. 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:**
- 5/5 committed stories Done, all acceptance tasks checked off; sprint goal assessed "met" at Sprint Review (`backlog/sprints/sprint-1.md`, Sprint Review Outcome).
- Test suite grew from 15 -> 47 -> 74 -> 106 across the sprint's batches, plus 5 more (111 total) added the same day for the post-review license-key fix.
- 1 impediment resolved same-day (Debenu license key access); 2 impediments still open (template asset path strategy, UNC timeout/retry), both assessed by product-owner as non-blocking for Sprint 2's likely candidate epics (2 and 3).
- 3 technical debt items logged: 1 deliberate/paid down same-day (exit code 64 placeholder), 1 unavoidable/resolved one batch later exactly as planned (double-launch guard), 1 unintentional/high-impact/resolved same day post-review (license key resolution — Debenu error 999).
- 1 process-improvement item logged by product-owner (2026-09-11, DoD verification-gap), carried into this retrospective for a decision.

**Subjective (from dev-team's daily-scrum notes):**
- Consistent pattern of finishing a batch, then immediately pulling the next in dependency order, all within a single day.
- Two instances of proactively fixing a bug found while working on an adjacent story rather than deferring it (spurious blank first page in Batch 2; double-launch guard flagged in Batch 4, closed in Batch 5).
- Consistent honesty about gaps rather than papering over them: the "no warning concept exists" finding was reported as a real gap instead of fabricating a counter; the unrun 100k-record benchmark was flagged explicitly in the daily log rather than silently skipped; the thin GUI verification evidence was named explicitly at Sprint Review rather than presented as equivalent to the CLI's much stronger evidence.

## What went well
- The dependency-ordered "Execution Order" batch table (sprint-1.md) let the team swarm one batch at a time, fully completing each vertical slice (design + build + test + verify) before pulling the next, with zero stories split across batches.
- "Leave it better than you found it": two real bugs were caught and fixed inline rather than logged and deferred — the Debenu default-first-page bug (Batch 2) and the Render-button double-launch gap (flagged in Batch 4, resolved in Batch 5 exactly as planned when that story's scope allowed it).
- Honest self-reporting of gaps (missing warning concept, unrun benchmark, thin GUI evidence) at the time they occurred, not discovered later — this is precisely what allowed product-owner's Sprint Review to catch and log the DoD gap instead of it going unnoticed.
- Open impediments and technical debt were tracked with clear status/resolution the whole sprint, not left ambiguous.

## What didn't go well
- A core happy-path bug (license key resolution for the desktop-launched CLI, Debenu error 999) reached "Done" on two stories and let `state.md` advance to Phase 4, because DoD verification for those GUI-launching stories used an in-process/dev-shell test harness rather than the actual built `.exe` an operator would run. It was only caught the same day via a real user report, not by the sprint's own verification step.
- The 100k-record/300 DPI release-quality benchmark was not re-verified after Batch 2, despite two later batches (3 and 5) touching the render/progress hot path. Self-flagged each time, but never re-run before Sprint Review.
- The sole GUI-facing acceptance evidence (Batch 5's completion-summary display) was thin — a prose description of a manual click-through, no screenshot or automated UI check — accepted by product-owner as adequate for this sprint's small surface area, but named as worth tightening.

## Patterns / Insights (prioritized)
1. **(Kit-level — decided below)** The DoD's "runnable in the current local development setup" bar doesn't distinguish "runs under a dev harness" from "runs as the actual shipped artifact the target user launches" — this is the direct, root cause of the license-key bug reaching Done undetected.
2. **(Team-level)** Dependency-ordered batch sequencing + swarming one batch fully before pulling the next is a genuine strength — worth reusing as the default planning pattern, not a one-off.
3. **(Team-level)** "Leave it better than you found it" plus honest gap self-reporting are cultural strengths that directly produced this retrospective's best signal (the DoD gap was visible at all only because the team reported it) — worth explicitly naming so they're preserved, not assumed to continue automatically.
4. **(Team-level, lower priority)** Hot-path-affecting stories should re-trigger relevant release-quality checks (e.g., the benchmark) rather than let them go stale silently across batches within the same sprint.

## Kit-level decision: DoD / verification-gap item (`logs/process_improvement_log.md`, 2026-09-11 row)

**Decision: propose a specific, minimal edit to `templates/definition_of_done.md`.** This meets `AGENTS.md`'s and `process/07_process_improvement.md`'s bar for a kit edit on a single occurrence — not because it recurred (it hasn't, yet), but because this one occurrence was severe: it let a Done story's core happy path silently fail for the actual target user (an operator double-clicking the shipped `.exe`), passed DoD sign-off on two stories, and let `state.md` advance to Phase 4 before a same-day real-user report caught it — the sprint's own verification process did not.

**Proposed edit (not applied — requires the user's explicit go-ahead per `AGENTS.md`'s Process Self-Improvement section and `process/07_process_improvement.md` step 5):**

File: `templates/definition_of_done.md`
Insert immediately after the existing line `- [ ] The change is implemented in working software under \`code/\` and is runnable in the current local development setup.`:

```
- [ ] If the story changes how the product is launched, packaged, or resolves runtime configuration (e.g., a new desktop entry point, a new child-process launch, a new license/config resolution path), verification includes running the actual built artifact the way the target user would run it — not only an in-process test harness or a dev-shell invocation such as `dotnet run`.
```

Kept deliberately narrow: it only fires for stories that change launch/packaging/config-resolution behavior (exactly the class of story that let this bug through), not every story — no blanket new burden on unrelated work.

This has been recorded in `logs/process_improvement_log.md` (Status updated to "Proposed" with this exact wording referenced). The scrum-master has **not** edited `templates/definition_of_done.md` itself.

## Action Items (added to Sprint 2's plan)
- [ ] Reuse the dependency-ordered "Execution Order" batch table as the default planning pattern for Sprint 2's committed stories — owner: dev-team (facilitated by scrum-master) — due: Sprint 2 planning.
- [ ] Until/unless the DoD template edit above is approved and applied, treat it as a working practice now: any Sprint 2 story that changes how the product is launched, packaged, or resolves runtime configuration must include an explicit task/acceptance step verifying against the actual built artifact, not only a dev harness — owner: dev-team — due: whenever such a story is pulled in Sprint 2.
- [ ] Pull "Time-box the first high-volume benchmark" early in Sprint 2 refinement (already flagged by product-owner at Sprint Review) and treat any later batch touching the render/progress hot path as a trigger to re-run it before marking that batch Done — owner: dev-team — due: Sprint 2.
- [ ] Explicitly continue the "leave it better than you found it" and honest-gap-reporting habits — no process change needed, just named as an expectation carried forward — owner: dev-team — due: ongoing.

## Deferred / lower-priority ideas (kept, not discarded)
- Strengthen GUI-facing verification evidence (e.g., a screenshot or a scripted UI check) instead of prose-only descriptions — folded into the DoD-adjacent action item above rather than made a separate Sprint 2 action; revisit if thin GUI evidence causes a problem again.
- Whether `templates/definition_of_done.md`'s release-quality benchmark checklist item needs an explicit re-run trigger (e.g., "re-run if the render/progress hot path changed since last verified") — noted for a possible future kit discussion; not proposed now since this is a single self-caught instance with no severity yet (no bug reached a user because of it).

## Follow-up on previous retro's actions
N/A — this is Sprint 1; no previous retrospective exists.

## Anti-patterns checked
- **No follow-through on prior retro actions:** N/A, no prior retrospective.
- **Blame-focused discussion:** Ruled out. Every log entry (daily scrum, tech debt, impediments) describes causes (env-var-only key resolution, harness scope, missing timeout/retry decision) in terms of the system and process, never attributing fault to an individual.
- **Hidden mini-waterfall within the sprint:** Ruled out. The daily log shows each batch built, tested, and verified together as one vertical slice in the same session — no evidence of design/build/test being split into separate sequential phases across days for a single story.
- **Avoiding an obvious known problem:** Ruled out. The two open impediments and the benchmark gap are actively tracked with explicit status and reasoning, not silently ignored — product-owner assessed both impediments non-blocking for Sprint 2's likely epics with a stated reason, and the benchmark gap has a named backlog story ("Time-box the first high-volume benchmark") flagged for early Sprint 2 pull.
- **Status-theater (near-miss, named explicitly):** Not full status-theater — no report overstated what had actually been done. But the Batch 5 GUI verification's prose-only, unscreenshotted evidence sits adjacent to this risk and is part of what let the DoD gap through undetected; it is addressed via the kit-level decision above and the corresponding Sprint 2 action item rather than logged as a separate anti-pattern instance.