Business Context

Nimbus is a B2B SaaS company with 14 engineering squads shipping product and platform work. After two quarters of mixed release outcomes, the CTO wants a consistent way to measure and report engineering delivery success to executives without encouraging teams to optimize for speed alone.

Metric Scenario

In the last quarter, Nimbus completed 420 planned tickets, shipped 18 customer-facing releases, and reduced average cycle time from 12.4 days to 9.1 days. However, post-release incidents increased from 11 to 17, on-time delivery for roadmap commitments fell from 82% to 74%, and escaped defect rate rose from 0.9 to 1.4 defects per 1,000 active users. Product leadership says engineering is "shipping faster but less predictably," while engineering managers argue throughput alone is an incomplete measure.

You are asked to define a delivery success framework and explain how it should be reported monthly and quarterly.

Requirements

1. Define a primary metric or metric set for engineering delivery success, including clear numerator, denominator, and reporting cadence.
2. Explain which metrics are leading indicators versus lagging indicators, and why both are needed.
3. Decompose the delivery outcome to identify whether speed, predictability, quality, or business impact is driving the mixed results.
4. Propose an executive dashboard with 5-7 metrics and explain how you would prevent metric gaming.
5. Recommend how to segment results across squads so comparisons remain fair.

Data Available

• jira_issues: issue_id, squad_id, issue_type, story_points, created_at, started_at, completed_at, planned_release_id
• deployments: deployment_id, squad_id, environment, deployed_at, release_id, rollback_flag
• incidents: incident_id, release_id, severity, opened_at, resolved_at, root_cause_team
• roadmap_commitments: quarter, squad_id, committed_item_id, due_date, delivered_at, status
• bugs: bug_id, release_id, found_at, severity, source (internal/customer), affected_users