Second pipeline time study: measure the effect of the #37 efficiency changes on the next comparable verity feature run #261

New issue

Open

opened 2026-08-26 13:48:02 +00:00 by jbr870 · 0 comments

jbr870 commented

2026-08-26 13:48:02 +00:00

Owner

Goal

Repeat the feature-230 time study once the #37 efficiency programme has fully landed, to measure
whether the 13 ranked changes actually moved the numbers. #37 filed the changes; this issue tests
their effect. Same method, same instrumentation, a comparable feature — so the two runs can be
compared line by line.

Baseline (verity #230, measured 2026-08-14)

13h 15m active session time end-to-end for one full-stack feature (in-app release notes).
31% of that was watching test suites — 7 full Playwright runs, six returning identical results.
2h 21m across four fix rounds on one defect class, which still ended deferred.
QA cost what /develop cost.
Ranked items 1–5 of #37 were expected to save ~4h 30m per feature of this size, with no change
to scope or verification depth.
Full detail: sdlc-dogfood-run-reports/verity-slot4-230.md and sdlc-retrospectives/2026-08-14.md
(both committed).

Preconditions

The remaining #37 children have landed and shipped in a release (so the run executes the new
skill text, not the old): #39, #43, #45, #47, verity#237; #46 is accepted and ships with the next
/dev:promote.
A new round of verity feature work is starting (the operator has one planned) with at least one
feature of comparable size and shape to #230: a full-stack feature driven through the entire
pipeline (/dev:requirements → /dev:technical-plan → /dev:develop → QA → /dev:integrate → UAT).

Plan

Pick the comparison feature from the upcoming verity round — comparable scope to #230, run
attended or supervised the same way, on a current release of the suite. Record which release ran
(the #57 provenance stamp covers this).
Instrument identically to the #230 study: end-to-end active session time, per-phase split,
share of time watching gates/test suites (and how many full-suite runs, how many redundant),
fix-round count and duration per defect class.
Write the study up as a committed run report + retrospective, like the baseline pair.
Produce a direct comparison table vs the #230 baseline, and where attributable, a per-change
verdict for the 13 ranked items (did the change fire during the run? did it save what was
projected?).
Feed any new findings back through /meta-retrospective as usual — this study is also the
natural moment to close #37 itself.

Acceptance

A second time-study report committed under sdlc-dogfood-run-reports/, with the comparison table
against the #230 numbers.
A per-ranked-change effect verdict where the run exercised the change (fired / didn't fire /
couldn't attribute).
Follow-up proposals, if any, filed as tracker issues through the meta lane.

## Goal Repeat the feature-230 time study once the #37 efficiency programme has fully landed, to measure whether the 13 ranked changes actually moved the numbers. #37 filed the changes; this issue tests their effect. Same method, same instrumentation, a comparable feature — so the two runs can be compared line by line. ## Baseline (verity #230, measured 2026-08-14) - **13h 15m** active session time end-to-end for one full-stack feature (in-app release notes). - **31%** of that was watching test suites — 7 full Playwright runs, six returning identical results. - **2h 21m** across four fix rounds on one defect class, which still ended deferred. - QA cost what `/develop` cost. - Ranked items 1–5 of #37 were expected to save **~4h 30m** per feature of this size, with no change to scope or verification depth. - Full detail: `sdlc-dogfood-run-reports/verity-slot4-230.md` and `sdlc-retrospectives/2026-08-14.md` (both committed). ## Preconditions - The remaining #37 children have landed **and shipped in a release** (so the run executes the new skill text, not the old): #39, #43, #45, #47, `verity#237`; #46 is accepted and ships with the next `/dev:promote`. - A new round of verity feature work is starting (the operator has one planned) with at least one feature of comparable size and shape to #230: a full-stack feature driven through the entire pipeline (`/dev:requirements` → `/dev:technical-plan` → `/dev:develop` → QA → `/dev:integrate` → UAT). ## Plan 1. Pick the comparison feature from the upcoming verity round — comparable scope to #230, run attended or supervised the same way, on a current release of the suite. Record which release ran (the #57 provenance stamp covers this). 2. Instrument identically to the #230 study: end-to-end active session time, per-phase split, share of time watching gates/test suites (and how many full-suite runs, how many redundant), fix-round count and duration per defect class. 3. Write the study up as a committed run report + retrospective, like the baseline pair. 4. Produce a **direct comparison table vs the #230 baseline**, and where attributable, a per-change verdict for the 13 ranked items (did the change fire during the run? did it save what was projected?). 5. Feed any new findings back through `/meta-retrospective` as usual — this study is also the natural moment to close #37 itself. ## Acceptance - A second time-study report committed under `sdlc-dogfood-run-reports/`, with the comparison table against the #230 numbers. - A per-ranked-change effect verdict where the run exercised the change (fired / didn't fire / couldn't attribute). - Follow-up proposals, if any, filed as tracker issues through the meta lane.

jbr870 added the

priority:medium

type:chore

phase/backlog

labels

2026-08-26 13:48:02 +00:00

jbr870 referenced this issue

2026-08-26 13:48:08 +00:00

Feature-230 time study: 13 ranked pipeline-efficiency changes #37