CTO delivery metrics
Provide a decision-oriented view that answers whether delivery is predictable, which projects are at risk and when work is likely to complete.1
Revalidated analytical foundation
Section titled “Revalidated analytical foundation”The repository implements a dedicated delivery-dashboard endpoint and React page in addition to story-point, per-user delivery, application, activity and organization analytics. The dashboard currently returns a status funnel, backlog and estimate coverage, throughput/velocity, linear ETA, WIP aging, quality ratios and a portfolio table; optional weekly commit and line-count aggregates are displayed as context.2
The admin request path is organization-admin protected and the inspected dashboard service derives issue scope from active projects selected by organization. This establishes the intended tenant boundary structurally; independent route-matrix verification remains required before production closure.2
The implemented formulas are a foundation, not yet the canonical interpretation of every displayed value. The current temporal, per-project workflow, rework/reopen and health-label gaps are ordered first in the CTO dashboard plan.2
Target metrics
Section titled “Target metrics”- issue and story-point funnel by workflow state;
- issue/story-point completion and remaining work;
- estimate coverage and size distribution;
- throughput and velocity trends;
- WIP count and aging;
- cycle/flow time percentiles;
- rework, reopen and bug ratios;
- project ETA with uncertainty bands;
- sprint predictability;
- portfolio-level health.
Data gaps
Section titled “Data gaps”- completion events do not snapshot story points, so historical SP totals currently inherit later estimate edits;
- planned story points at sprint start require a snapshot or dedicated field;
- business-day calculations need a calendar policy;
- labels/exclusion semantics are not fully represented;
- pull-request/review lifecycle lacks a dedicated model;
- forecast history needs durable snapshots to measure drift.
Temporal model
Section titled “Temporal model”Dashboard metrics use three distinct clocks:
- current state: present issue status, estimate, WIP and backlog composition;
- event window: transitions and completions between an inclusive
fromandto; - snapshot history: immutable recorded backlog, estimate and sprint scope as of a past instant.
The UI and API must identify the clock for each metric. A date filter cannot make current mutable issue fields represent a historical backlog. Rolling windows are anchored to the selected to, not the server wall clock.
Metric rules
Section titled “Metric rules”Metric definitions must specify population, numerator, denominator, sample size, time window, timezone, workflow state mapping, exclusions, treatment of unestimated work and multi-assignee allocation. Performance aggregations execute in bounded database queries and always include tenant scope.
- Completion is reported separately for issue count and estimated story points.
- Estimate coverage is estimated eligible issues divided by all eligible issues; organization coverage is weighted from aggregate counts, not averaged project percentages.
- Throughput counts distinct qualifying completion events in complete week buckets. Reclose behavior follows one explicit, tested rule.
- Reopen rate counts distinct issues moving from a project-defined done state to a non-done state against the documented completed population; done-to-done transitions are excluded.
- Rework derives from qualifying
isReworktransitions and is not restricted to completion transitions. - WIP age is time in current workflow state. Missing transition history is unknown or explicitly sourced from a fallback, never zero by default.
- ETA/forecast is unavailable when history, sample size or estimate coverage is below the accepted threshold. Every forecast carries its data window and confidence.
- Commit/LOC trends are contextual activity measures, not delivery outcomes, health inputs or individual-productivity scores.
Health score caution
Section titled “Health score caution”The implemented portfolio label currently uses only estimate coverage and zero velocity, so it must remain experimental and must not claim that a project is on track. A future composite may use forecast drift, estimate coverage, rework and WIP aging only after those components, thresholds, missing-data behavior and calibration are accepted. Always expose the underlying signals so a single score cannot hide uncertainty.2
Implementation sequencing is maintained in CTO dashboard plan.