13KB

Rå Blame Historik

Sprint Retrospective

Sprint: 7 Date: 2026-10-19 Facilitated by: scrum-master, per process/05_sprint_retrospective.md Inputs used: backlog/sprints/sprint-7.md (Daily Scrum Log + Execution Order), backlog/backlog.md (Sprint 7 planning, backlog refinement, and Review outcome notes), backlog/epics/04_live_preview_and_record_navigation.md, backlog/epics/06_layout_efficiency_and_operator_tooling.md, logs/technical_debt_log.md, logs/impediment_log.md, logs/process_improvement_log.md, backlog/sprints/sprint-6-retrospective.md (for follow-through check), backlog/sprints/sprint-3-retrospective.md and sprint-5-retrospective.md (for prior watch-item context). No live human team to poll in real time; subjective signals are synthesized from dev-team's daily-scrum notes and product-owner's independent review notes, including a disclosed tooling limitation on the review side (see below). An independent dotnet test run by the top-level session, outside this retrospective, confirmed 400/400.

Signals

Objective:

3/3 committed stories Done (18/18 points), sprint goal assessed “met in full” at Sprint Review (backlog/backlog.md, Sprint 7 Review outcome).
Test suite grew from 349/349 (Sprint 6 close) to 400/400 (101 CLI + 299 desktop) — confirmed twice independently: once by product-owner's static [Fact]/[Theory]/[InlineData] count during review (no shell access that session), and once by a live dotnet test run performed afterward by the top-level session. Both landed on exactly 400/400 with no discrepancy.
Zero new impediments; the two pre-existing open impediments (asset path strategy, UNC timeout/retry) remain non-blocking and untouched, as expected since neither epic 4 nor epic 6 touches image assets or network paths.
One new Low-impact technical debt item logged and reviewed (Address Control lines visually overlapping at small font sizes, canvas/preview-only, confirmed by product-owner not to touch the real DebenuPdfRenderer/RenderEngine path) — correctly scoped as cosmetic and non-blocking, not swept under the rug.
Live verification: a real built-.exe reflection harness drove the actual TemplateDesignerForm/TemplateCanvasControl/TemplatePreviewControl for Batches 1-2 (full-form screenshots proving no dock/clipping regression, real rotated-pivot stability across differently-sized names, real out-of-range record navigation against the 392-record sample CSV), and a canvas-only bitmap smoke for Batch 3 (continuous mid-drag grid snapping, confirmed via intermediate-vs-final position assertions).

Subjective:

Dev-team deliberately designed the new preview panel's layout with a deterministic two-column TableLayoutPanel specifically to avoid repeating the Sprint 6 dock-order bug class — a proactive application of a lesson learned, not just a reactive fix.
Record navigation reused the CLI's already-proven CsvRecordSource streaming pattern (CsvRecordNavigator) rather than building new indexed/random-access infrastructure, consistent with this team's standing “reuse over rebuild” discipline.
Product-owner's Sprint Review this sprint lacked shell/build tool access. Rather than silently presenting a lighter check as full re-verification, product-owner explicitly disclosed the substitution (an independent [Fact]/[Theory]/[InlineData] count in place of dotnet test, and code-level reading in place of a live built-.exe re-run of dev-team's screenshots) and flagged it as “a review-process limitation ... not a defect in the sprint's delivery.” The top-level session's own dotnet test run afterward matched exactly, so the substitution did not in fact hide any discrepancy this time.

What Went Well

Full follow-through on all three Sprint 6 retrospective action items, discussed in detail below — the sixth clean full-follow-through sprint in a row.
The differentiated built-form-vs-canvas-only smoke rule (Sprint 6's carry-in) was applied with real judgment, not applied uniformly by rote: full-form smokes where form layout was actually touched (Batches 1-2), a lighter canvas-only smoke where it genuinely wasn't (Batch 3) — and the story notes state the reasoning for each choice explicitly rather than leaving it implicit.
Product-owner's honest disclosure of a tooling limitation (no shell/build access) is a repeat of this team's established “surface the gap, don't smooth it over” norm, seen previously with dev-team's own self-reported gaps (Sprints 1, 3, 5).

What Didn't Go Well

Batch 2 (“Jump to a specific record number”) added a new toolbar affordance (NumericUpDown + “Go” button) to the same TemplateDesignerForm surface Batch 1 had just full-form-screenshotted, but verification for Batch 2 relied on the same harness/session rather than capturing a fresh full-form screenshot after the new control was added. No layout regression resulted (the deterministic TableLayoutPanel used for Batch 1 held), but this is a narrower instance of the same risk class the built-form-smoke rule exists to catch — worth naming rather than assuming the Batch 1 screenshot fully covers a subsequently-added control.
Product-owner's Sprint 7 review ran without shell/build tool access, substituting a static test-attribute count and code reading for an actual dotnet test run and a live re-run of dev-team's built-.exe screenshots. This was disclosed honestly and turned out to match exactly when independently re-run — but it is a real gap in verification depth for that session, not merely a stylistic difference from prior reviews.

Patterns / Insights (Prioritized)

(Team-level) The built-form-vs-canvas-only smoke rule from Sprint 6 is now demonstrated working as a genuine judgment call, not a blanket policy — worth continuing to apply story-by-story rather than defaulting to either extreme.
(Team-level, minor) A new toolbar/panel control added to an already-screenshotted form should get its own fresh full-form check, not ride on an earlier batch's screenshot of the same form — a narrow refinement of the existing rule, not a new rule.
(Process-level, new this sprint) Product-owner review capability (shell/build tool access) varied session-to-session and directly affected verification depth this sprint. This is a different category from the Sprint 3 PO-review-independence watch item (which was about whether PO forms its own judgment versus leaning on dev-team's pre-written narrative — a judgment-independence question, resolved structurally at Sprint 4). This sprint's gap is about PO's tooling access, not its independence of judgment — PO still read the real code and formed independent conclusions; it just couldn't execute a live build/test pass. First occurrence of this specific shape; logged as a watch item, not conflated with the earlier, already-closed item.

Action Items (Add These To Sprint 8's Plan)

For Sprint 8's epic 6 multi-select/align pair: apply the built-form-vs-canvas-only smoke rule explicitly per story. “Select multiple elements at once on the canvas” is likely canvas-only (canvas-only smoke may suffice); “Align and distribute multiple elements” may add new toolbar/menu affordances (alignment buttons) and should get a full built-form smoke if it does — decide per the actual UI surface touched, not by analogy to Sprint 7's snap-to-grid story — owner: dev-team — due: Sprint 8.
When a later batch in the same sprint adds a new control to a form surface an earlier batch already full-form-screenshotted, capture a fresh full-form screenshot after that addition rather than relying on the earlier batch's screenshot to cover it — owner: dev-team — due: Sprint 8, ongoing.
If product-owner's Sprint 8 review session again lacks live shell/build access, disclose it explicitly (as done this sprint) and arrange an independent dotnet test / built-.exe cross-check before treating verification as complete — owner: product-owner / scrum-master — due: Sprint 8 review.

Deferred / Lower-Priority Ideas

Address Control line-overlap-at-small-font-sizes (Low-impact, canvas/preview cosmetic only) — revisit only if an operator reports it as more than cosmetic; not a Sprint 8 candidate on its own.
The still-open product question on “Warn on text overflow before render” (epic 4) remains parked for the human product owner to resolve whenever convenient; not blocking Sprint 8.

Follow-Up On Previous Retro's Actions

All three of Sprint 6's retrospective action items were carried into Sprint 7's plan. Checked against backlog/sprints/sprint-7.md and backlog/backlog.md's Sprint 7 planning/review outcomes:

Built-form smoke for GUI-facing stories touching form layout/properties/toolbar actions — Applied, and correctly, not diluted. The action item's own original wording distinguished full-form smokes (for form-layout/properties/toolbar stories) from canvas-only smokes (for canvas-only changes) — this sprint's two epic-4 stories (which genuinely touch TemplateDesignerForm layout) got a real built-.exe reflection harness with full-form screenshots explicitly checked for dock/clipping regressions, while “Snap elements to grid and guides” (which touches only CanvasElementEditor/TemplateCanvasControl mouse handlers, no form/panel/toolbar surface) correctly got a canvas-only smoke per its own story notes. Judged as genuine follow-through: the differentiation is exactly what the rule called for, not a shortcut around it. One minor gap noted above (Batch 2's new toolbar control riding on Batch 1's screenshot) keeps this from being a perfect follow-through, but the substance of the rule was honored.
Product-risk-first ordering — Held. Confirmed at both planning (backlog/backlog.md's Sprint 7 planning outcome: “the epic 4 pair is pulled first because it closes a known-shape defect class ... ‘Snap elements to grid and guides’ is pulled last as the lowest-risk item”) and in backlog/sprints/sprint-7.md's Execution Order table, which sequences by product risk first, then dependency.
Cross-layer code-inspection sizing for composite/multi-part stories — Confirmed genuinely held, not just asserted. The 2026-10-16 backlog refinement outcome cites specific real code paths inspected for both stories: TemplateCanvasControl, AddressBlockPreviewCalculator, RenderEngine, TemplateDesignerForm for the preview story, and CanvasElementEditor.DragTo/BeginDrag/EndDrag plus TemplateCanvasControl's paint routine for snap-to-grid (backlog/epics/04_live_preview_and_record_navigation.md, backlog/epics/06_layout_efficiency_and_operator_tooling.md, both dated 2026-10-16). These are specific method/class names tied to the actual sizing decision, not a surface-level UI description — this is real evidence of the practice, not a restated claim.

No drops. This is the sixth clean full-follow-through sprint in a row, with one minor, honestly-named nuance on item 1 rather than a clean pass claimed where it wasn't fully earned.

Kit-Level Decision

No kit edit proposed. The PO-review tooling-access gap (item 3 in Patterns/Insights) is a first-occurrence, non-severe issue — it did not produce a wrong verdict (the independent dotnet test cross-check matched exactly), and it was disclosed rather than hidden. Per AGENTS.md's bar (a recurring 2+-occurrence pattern, or one occurrence severe enough to have visibly broken the sprint), this does not qualify for a kit edit. Logged to logs/process_improvement_log.md as a new “Watching” entry, explicitly distinguished from the Sprint 3 PO-review-independence item (already closed, a different category — judgment independence, not tooling access) rather than folded into or reopening that closed entry.

Anti-Patterns Checked

No follow-through on prior retro actions: Ruled out; all three Sprint 6 actions were applied, with one honestly-named minor nuance on item 1 rather than an overstated clean pass.
Blame-focused discussion: Ruled out; the toolbar-screenshot gap and the PO tooling-access gap are both described as process/environment characteristics, not attributed to a person.
Hidden mini-waterfall within the sprint: Ruled out; all three batches were designed, implemented, tested, documented, and live-verified within their own batch, consistent with every prior sprint.
Avoiding an obvious known problem: Ruled out; the still-undefined “text overflow” product question was correctly left Not Ready and explicitly flagged rather than guessed at or silently dropped, and the new Address Control overlap debt was logged rather than smoothed over.
Status-theater: Ruled out; evidence is concrete and independently checkable (exact test counts confirmed twice by two different methods, real screenshots, exact grid-snap coordinate values, an out-of-range navigation message matched to source).
Review rubber-stamping (Sprint 3-named, resolved Sprint 4, checked again here): Ruled out. Despite lacking shell access, product-owner's Sprint 7 review read the actual changed source files directly (TextResolver.cs, RotationPivotCalculator.cs, TemplatePreviewBuilder.cs, etc.), traced the real auto-refresh wiring path rather than trusting the claim, and independently confirmed the technical debt item's root cause and scope. The tooling-access gap (item 3 above) is a distinct, narrower issue from rubber-stamping and is tracked separately, not conflated with it.

13KB Rå Blame Historik