⚙️ R&D Workforce Governance 7-Item KPI Engine

Autonomous Engineering Measurement: AI plans the daily to-do list · AI verifies completion by reading code & logs.

📋 AI-Arranged Daily To-Do List

Select an engineer and date to view their AI-assigned daily tasks.

🎯 2-Measurement Daily KPI

KPI 1 · Time Match
—
0h logged / 0h budgeted
No Hours
KPI 2 · AI Progress
—
0/0 AI tasks verified
No Tasks

🤖 AI Audit & Governance Narrative

No KPI snapshot calculated yet. Complete tasks with verification evidence to generate autonomous scorecards.

📐 Linear Insights Metrics vs. Kaser Autonomous R&D Measurement Architecture

Why Kaser R&D Workforce keeps Linear's UX primitives (Teams, Cycles, Projects, Tasks) while replacing the human-scored measurement layer with autonomous AI telemetry.

Architecture Spec

📊 Linear's Built-in Measurement Metrics (Insights)

# Linear Metric What It Measures Kaser Autonomous R&D Evolution
1 Cycle completion rate % of issues scheduled for a cycle that got closed by cycle end AI-Weighted Deliverable Completion (% against verified commits & tests)
2 Throughput Count of issues closed per cycle / week / day Verified Task Output per Day (backed by Git SHAs & PRs)
3 Velocity Sum of story-point estimates closed per cycle (if teams estimate) 3-Way Signed Hours & Dynamic AI Weights (0–100 Daily KPI)
4 Scope added / removed mid-cycle Issues added or deferred after the cycle starts (sprint-churn) Autonomous Daily Scope Rebalancing via AI To-Do Arrangement
5 Lead time Time from issue created → done Linear Issue Creation → PR Verified Lead Time Telemetry
6 Cycle time Time from started → done (excludes backlog wait) Active Working Window & Time Log Duration per Work Block
7 Issue age How long each open issue has been sitting in its current state Stalled Deliverable Alerting & Priority Weight Escalation
8 Workload per assignee Count / point-sum of open issues per person Daily Capacity vs. Assigned AI Weight Budget (8h / 100 pts)
9 Burndown / burnup Remaining or completed scope plotted over cycle days Release Gate Readiness Burnup (Gate 1 QA → Gate 2 Defect → Gate 3 Demo)
10 Triage queue depth Unassigned incoming issues waiting on triage Autonomous Issue Ingestion & AI-Triaged Priority Labeling

⚠️ Characteristics of Linear's Model

  • Count- or point-based, not hours-based: No built-in time logging; requires 3rd-party add-ons to verify actual operational investment.
  • Volume-centric: Closing more trivial issues yields better numbers regardless of true business or technical difficulty.
  • Human-planned: Humans create issues, humans estimate points, and humans manually decide cycle scope in lengthy meetings.
  • Human-scored: Retrospectives and performance appraisals are subjective meetings, not deterministic algorithms.
  • No code-quality dimension natively: Review turnaround, defect escape, test density, and perf regressions need LinearB / Jellyfish / Swarmia on top.
  • No "did you follow the plan" dimension: If an engineer closes 20 random issues, Linear reports it the same as closing 20 planned ones.

✨ Why Kaser Keeps Linear's Shape but Swaps Measurement

Linear's primitives (teams, cycles, projects, tasks, workflow states) are kept because engineers like the UX. But Linear's measurement layer is replaced by:
  • Hours (actual ÷ required, 3-way-signed) instead of subjective story points.
  • AI-arranged daily to-do list instead of human-authored sprint grooming.
  • AI-measured completion against multi-modal evidence (commits, PRs, issue updates, time logs, doc edits) instead of human retro scoring.
  • Code performance & Release Gates as first-class KPI components (via GitHub signals, automated pytest suites, and demo walkthrus), not relegated to 3rd-party add-ons.