You’re viewing Paradaux’s public workspaceSign in to vote Get taskl.ie for your team

PAR-212

Loading issues

PAR-212 · Issue-delivery analytics: throughput, cycle/lead time per… · Paradaux · taskl.ie

PAR-212· sub-issue of PAR-192

Issue-delivery analytics: throughput, cycle/lead time per status, churn, status aging, burndown

Remaining scope of PAR-192 after the DORA dashboard shipped (tesks-ui/app/(app)/w/[workspace]/analytics/page.tsx + lib/sql/analytics.ts getDora + AnalyticsCharts). The issue-delivery metrics — the part that distinguishes this from usage/billing reporting (PAR-203) — are not built:

Throughput (issues completed per period), churn (reopened), status aging (time sitting in each state), cycle/lead time per status, burndown (sprint progress, ties to PAR-199).
Aggregation queries: extend lib/sql/analytics.ts (only getDora today) with these; respect RBAC (who can see workspace analytics).
Charts/sections: more AnalyticsCharts components + analytics-page sections (recharts already in use).
State-transition history: per-status timing currently must be reconstructed from issue_event rows where kind='status' (there's no dedicated history table). Decide: derive from issue_event (cheaper, lossy if events were ever pruned) vs add a status_history table written on state change. Needed for accurate per-status lead/aging.

Activity

tesks created the issue Jun 17
tesksJun 17
Progress shipped (tesks-ui 7229393): throughput (completed/week + 90d), cycle time (median created→done + weekly trend), and status aging (open issues by current state with median time-in-state, derived from the last issue_event kind='status'). New getFlow DAL, ThroughputChart/CycleTimeChart, and a "Delivery flow" section + aging table on /analytics. Typecheck clean.

Still remaining on this issue:
- Churn (reopen rate) and proper per-status lead/cycle time — both need a reliable state-transition history; today completed_at is nulled on reopen so reopens aren't distinguishable, and per-status durations can only be approximated from issue_event. Decide derive-from-events vs a status_history table.
- Burndown — needs sprint windows (ties to PAR-199 sprint dates).
tesks set status to In Progress Jun 17
ParadauxIO linked a commit: Commit cc2f7b6 — Emit a 'reopened' event on completed→open transitions (PAR-212 churn signal) Jun 17
tesks set status to Done Jun 17
tesksJun 17
Complete. Beyond the earlier throughput/cycle-time/status-aging, this adds:
- Churn: a reopened issue_event is now emitted on completed→open transitions (tesks cc2f7b6, tested), and the analytics page shows a Churn card (reopened/90d + % of completions) + a weekly reopened chart.
- Sprint burndown: open-issues-remaining over the active sprint's window (getActiveSprintBurndown) as a line chart.
Shipped tesks-ui c0a38d7 and browser-verified in the seeded harness (Churn card, reopened chart, and the Sprint-1 burndown curve all render). Closing PAR-212.
ParadauxIO linked a commit: Commit b7c9211 — Analytics: issue-delivery flow metrics — throughput, cycle time, status aging (PAR-212) Oct 13
ParadauxIO linked a commit: Commit ed1bd8a — Analytics: churn + sprint burndown (PAR-212) Oct 13

Workspace permission required to comment

Comments and reactions require workspace permission. Ask a workspace owner or admin for access. You can sign in to vote.