10KB

Rå Blame Historik

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)

(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.
(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.
(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.
(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.

10KB Rå Blame Historik