25'ten fazla konu seçemezsiniz Konular bir harf veya rakamla başlamalı, kısa çizgiler ('-') içerebilir ve en fazla 35 karakter uzunluğunda olabilir.

11KB

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.

Powered by TurnKey Linux.