12KB

Raw パーマリンク Blame 履歴

Sprint Retrospective

Sprint: 5 Date: 2026-10-09 Facilitated by: scrum-master, per process/05_sprint_retrospective.md Inputs used: backlog/sprints/sprint-5.md (Daily Scrum Log + Execution Order), backlog/backlog.md (Sprint 5 Review outcome), backlog/epics/08_composite_address_controls.md and 05_cli_rendering_engine_and_debenu_integration.md (Sprint Review verification notes), logs/technical_debt_log.md, logs/impediment_log.md, logs/process_improvement_log.md (all three untouched this sprint — confirmed via diff), backlog/sprints/sprint-4-retrospective.md (for follow-through check). No live human team to poll in real time; subjective signals are synthesized from dev-team's own daily-scrum notes and product-owner's independent review notes.

Signals

Objective:

2/2 committed stories Done (15/15 points), sprint goal assessed “met in full” at Sprint Review (backlog/backlog.md, Sprint 5 Review outcome).
Test suite grew from 288 (Sprint 4 close) to 330/330 (91 CLI + 239 desktop) — 42 new tests, with all 233 pre-existing tests passing completely unmodified, a strong regression signal for a story whose central risk was backward compatibility.
Zero new impediments and zero new technical debt logged this sprint (confirmed by diff).
The CLI Rendering Engine and Debenu Integration epic is now Done outright (6 of 6 stories) — closing out an epic that has been open since Sprint 1.
One infrastructure event, not a project defect: the background agent executing this sprint's work hit a transient API/network failure mid-task and was resumed from its partial progress with no work lost and no quality impact on the delivered stories — the first real-world test of this project's “resume from task-id” recovery path.

Subjective (from dev-team's daily-scrum notes and product-owner's independent review):

Empirical-verification discipline reached a new high point this sprint: to prove the highest-risk acceptance criterion (existing templates render identically after this story), dev-team built the actual pre-Sprint-5 CLI binary from a git worktree at the prior commit and byte-compared its real output against the new binary's — then controlled for Debenu's own internal nondeterminism by running the old binary against itself twice, isolating the remaining diff to known-nondeterministic tokens only. This is a meaningfully more rigorous instance of the “confirm real behavior, don't assume” pattern named in Sprints 3 and 4, since it required constructing a whole separate historical artifact for comparison, not just probing a single API call.
Sizing-note predictive accuracy held again, on a much larger story than Sprint 4's example: the sizing note predicted DebenuPdfRenderer would need zero changes since a run sequence only needs to be concatenated into the one string TextDraw already expects — and the actual implementation confirmed exactly that.
Honest self-reporting continued, including a second disclosed trade-off in the same sprint (not hidden or downplayed): the bracket-syntax editing convention's known limitation (a literal {...} not meant as a token gets parsed as one), documented plainly in TEMPLATE_FORMAT.md.
“Leave it better than you found it” continued: a live-caught GUI bug (RefreshSelectionLabel showing a blank "{}" for mixed-content elements) was found and fixed in the same verification pass.
A GUI verification automation issue surfaced: mouse-coordinate clicks proved unreliable (an apparent DPI-scaling mismatch between the automation script's coordinate space and the real screen), worked around by switching to keyboard-based input instead. This is a different specific issue than Sprint 4's SetForegroundWindow focus-stealing glitch, but the same broad category — GUI automation environment friction — recurring in back-to-back sprints.

What went well

Full follow-through on all three Sprint 4 retrospective action items, the fourth clean full-follow-through sprint in a row (see “Follow-up” below).
This team's largest single story to date (13 points, a breaking internal model change) was delivered with zero regressions across 233 pre-existing tests — strong validation that the “computed backward-compatibility projections over an internal restructure” design (keeping StaticText/ColumnName/IsDynamic as derived views over the new Runs list) was the right call, not just a hopeful assumption.
The background-execution-agent recovery path was exercised for real (not just designed-for) this sprint, and it worked cleanly — a transient infrastructure failure cost some turnaround time but zero delivered-work loss.
Product-owner's Sprint Review treated dev-team's mid-sprint production-configuration decision as something to independently evaluate, not rubber-stamp — the confirmation note in backlog/epics/05_cli_rendering_engine_and_debenu_integration.md gives its own independent reasoning rather than restating dev-team's, consistent with the structural fix that resolved Sprint 3's PO-review-independence watch item.

What didn't go well

GUI verification automation friction showed up for a second consecutive sprint — a different specific root cause each time (Sprint 4: window-focus stealing; Sprint 5: mouse-coordinate DPI scaling), but the same broad category. Neither instance masked a real product defect (both were caught immediately and worked around), so this isn't a quality gap — but two occurrences in two sprints is enough to stop treating it as a one-off, especially with Sprint 6's likely next story (the Address Control, with list-management UI and a two-level selection model) needing even more GUI automation surface.
The transient background-agent API/network failure cost real turnaround time mid-sprint, though it was fully recovered from. Nothing actionable here beyond continuing to use the demonstrated resume path — it's an external infrastructure event, not a team or process failure.

Patterns / Insights (prioritized)

(Team-level) Empirical verification-before-claiming discipline keeps growing in rigor, not just repeating — this sprint's real-historical-binary byte-comparison is a step up from Sprint 3's DLL probes and Sprint 4's sign-convention check. Worth continuing to invest verification effort proportional to a claim's real risk, as happened here.
(Team-level) Sizing-note predictive accuracy is now confirmed on both a small story (Sprint 4's drag-handle reuse) and this team's largest story to date — strong evidence the code-inspection-backed sizing practice generalizes, not just works on easy cases.
(Team-level, new) GUI verification automation reliability has recurred as friction twice in two sprints, different root cause each time. Per this project's own recurrence bar, this now warrants a deliberate look rather than another “revisit if it recurs” deferral — added as a Sprint 6 action item below, not left deferred a second time.
(Process-level, positive, not a kit matter) The background-agent resume-from-failure path is now proven under real conditions, not just theoretical — worth noting as a demonstrated strength of how this project delegates large implementation work, but this is an operational/tooling observation, not a Scrum-kit (process//templates//.claude/agents/) insight, so it stays here rather than in logs/process_improvement_log.md.

Kit-level decision

No kit edit proposed or logged this retrospective. Nothing found rises to a Scrum-kit-level insight (about process/, templates/, .claude/agents/, or AGENTS.md itself) — both findings above (GUI automation friction, the infrastructure recovery event) are team/tooling-level, not kit-level, and are handled as retrospective action items and observations instead.

Action Items (added to Sprint 6's plan)

Continue empirical vendor/spec/format verification before implementing render- or format-affecting code — no process change, a standing expectation now demonstrated at increasing rigor across four sprints — owner: dev-team — due: ongoing.
Continue live actual-built-artifact verification for every GUI-facing story — owner: dev-team — due: ongoing.
Look into hardening GUI verification automation reliability (coordinate-space/DPI-scaling and window-focus issues have each surfaced once) before or during Sprint 6's likely Address Control story, which will need more GUI automation surface than any story so far (list management, two-level selection) — owner: dev-team — due: Sprint 6, opportunistic (not a blocking gate on the story itself).
No action needed on the transient background-agent failure beyond continuing to use the demonstrated resume-from-task-id recovery path — owner: n/a — due: n/a (already resolved cleanly).

Deferred / lower-priority ideas (kept, not discarded)

The pre-existing “unrelated elements coincidentally sharing X position” ambiguity in AddressLineCollapser's grouping rule, flagged in backlog/epics/08_composite_address_controls.md's own notes — still not required by any committed story's acceptance criteria, but will become directly relevant once “Group lines into a single, movable Address Control” (Sprint 6's likely pull) actually lands. Revisit then, not now.

Follow-up on previous retro's actions

All three of Sprint 4's retrospective action items were carried into Sprint 5's plan and applied, confirmed via backlog/sprints/sprint-5.md's Notes section and Daily Scrum Log:

Continue empirical vendor/spec verification before implementing render- or format-affecting code — Applied, and exceeded: the AC2 backward-compatibility proof (building and byte-comparing an actual historical binary) is more rigorous than any prior instance of this practice.
Continue live actual-built-artifact verification for every GUI-facing story — Applied: the mixed-content editing UI was verified against the real built .exe with real input injection, adapting in real time when mouse-coordinate automation proved unreliable.
Apply the same code-inspection-backed sizing rigor to epic 08 when it's next refined — Applied: both epic-08 stories were sized on 2026-09-29 (ahead of this sprint) with the same rigor as the throughput and rotation stories, and this sprint's actual implementation confirmed the sizing note's specific technical predictions.

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

Anti-patterns checked

No follow-through on prior retro actions: Ruled out — all three Sprint 4 actions were applied, one of them exceeded (see above).
Blame-focused discussion: Ruled out. Both frictions found (GUI automation reliability, the background-agent network failure) are described as environment/tooling characteristics, never attributed to a person or treated as a mistake.
Hidden mini-waterfall within the sprint: Ruled out. Both batches were designed, built, tested, and live-verified together in one pass, consistent with Sprints 1-4.
Avoiding an obvious known problem: Ruled out. Both disclosed trade-offs this sprint (the bracket-syntax parsing limitation, the mouse-coordinate automation issue) were surfaced and documented rather than smoothed over.
Status-theater: Ruled out. This sprint's central claim (backward compatibility) was proven with the strongest evidence standard used yet — a real historical binary byte-comparison, not a description of what should be true.
Review rubber-stamping (the Sprint 3-named watch item, resolved Sprint 4, checked again here rather than assumed permanently fixed): Ruled out again — product-owner's confirmation of the production-configuration decision gives independent reasoning (deployment model, exposure risk, absence of a packaging story) rather than restating dev-team's framing.

12KB Raw パーマリンク Blame 履歴