>> Browse services
>_ProductScope StudioFrom an idea to a shareable PRD_> Open_> Open_> SIX LAYERS
01 / 06Six layers keep claims honest. Adoption without flow is theater. Throughput without quality is debt. Economics without all of the above is guessing.
DEFINITIONS
Count accepted change carefully. Baseline before uplift. Keep quality beside throughput.
01
Work counts only when it has a requirement or ticket, implementation, required verification, approval, production release, and no qualifying immediate revert or defect in the defined window.
02
Pull 8–12 historical weeks from ticketing, Git, CI/CD, and incident systems. Segment by seniority, task type, complexity, and repository. Do not rely primarily on developer self-report. Each scorecard metric has a baseline recipe in the dictionary below.
03
Cost per Verified Delivery Unit (VDU), or cost per accepted complexity point until VDU maturity. Include loaded engineering cost, AI/tool cost, managed-adoption cost, and optionally attributable CI compute.
04
Classify before implementation. Relative weights, not hours. Calibrate examples with the client and keep raw outcomes visible.
METRIC DICTIONARY
Same definitions power Measurement, Scorecard, Playbook, and Process Day 1. Expand a metric for systems of record, baseline and after recipes, sample rules, gaming guards, and CTO/CFO objection handling.
Never rank individuals by tokens, prompts, or LOC.
Report quality and cost beside every throughput claim.
Lock complexity weights before the pilot cohort starts. Recalibration mid-cohort voids the comparison.
Segment by repo, seniority band, and work type when mix shifts.
Prefer system timestamps over developer self-report.
Publish sample size and exclusion rules with every delta.
DEFINITION
Accepted complexity points delivered per engineer in a fixed calendar period. A point counts only when the change meets the accepted-change definition: ticket, implementation, required verification, approval, production release, and no qualifying revert or defect in the defined window.
SYSTEMS OF RECORD
BASELINE · BEFORE
Pull 8–12 historical weeks for the pilot team and repos. Tag each accepted change with a pre-agreed S/M/L/XL weight. Sum points, divide by active engineer-weeks in the same window. Exclude freezes and known outages with a written rule.
AFTER · PILOT
Same definition, same weights, same team and repos. Tag pilot-cohort work explicitly. Compare like calendar lengths (e.g. 4 weeks vs 4 weeks). Publish raw accepted-change count beside the normalized rate.
MIN SAMPLE
At least 20 accepted changes in each compared window, or state that the pilot is directional only.
WHEN NOT TO CLAIM
Major roadmap mix shift (e.g. all platform work vs all features), headcount change above 20%, or complexity weights changed after baseline closed.
GAMING GUARDS
OBJECTION HANDLING
CTO OBJECTION
“This is story points with a new hat. We already game them.”
REPLY · Weights are relative and locked before work starts. We publish raw accepted changes and quality gates beside the rate. If points inflate without quality holding, the gate fails and we do not claim uplift.
CFO OBJECTION
“More points does not mean more business value.”
REPLY · Correct. Throughput is capacity, not revenue. Pair it with cost per accepted point (or VDU) and quality. ROI models use quality-adjusted capacity, not points alone.
PROPOSED REPORTING SHAPE
Illustrative sponsor readout. Placeholders until your baseline and pilot close. Always pair throughput with quality and cost.
+0%
QUALITY-ADJUSTED THROUGHPUT
−0%
HUMAN SUPPORT PER DELIVERED UNIT
flat
CHANGE FAILURE RATE
−0%
TOTAL COST PER VERIFIED UNIT
CAVEATS
01
Caveats 01. Always report quality guardrails beside throughput.
02
Caveats 02. Sample size, product mix, and org changes limit attribution.
03
Caveats 03. Human support minutes may use sampling when systems cannot provide precise telemetry.
04
Caveats 04. Example scorecard numbers are not client results.