engineering-metrics

Measure engineering team performance using DORA metrics, SPACE framework, and cycle time analysis.

1|Updated Aug 10, 2026
One-click install
npx skills add https://github.com/TheViziusGroup/vibe-engineering-skills --skill engineering-metrics-theviziusgroup
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: engineering-metrics
Source: https://github.com/TheViziusGroup/vibe-engineering-skills/tree/main/plugins/agile-delivery/skills/engineering-metrics
Command: npx skills add https://github.com/TheViziusGroup/vibe-engineering-skills --skill engineering-metrics-theviziusgroup

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineering leaders struggle to measure team performance without falling into harmful traps like story point targets, lines-of-code counting, or individual activity surveillance. This Skill provides a research-grounded framework for measuring software delivery performance, team health, and productivity using validated multidimensional metrics. ## Core Features & Use Cases - DORA Four Key Metrics: Benchmarks, definitions, and Azure DevOps instrumentation guidance for deployment frequency, lead time, change failure rate, and failed deployment recovery time. - SPACE Framework: Five-dimension measurement model (Satisfaction, Performance, Activity, Communication, Efficiency) with a ready-to-use dashboard template. - Cycle Time Breakdown: Phase-by-phase bottleneck diagnosis from coding through production deployment, with typical fixes for each bottleneck. - OKR Templates & Anti-Patterns: Engineering OKR examples, executive dashboard templates, and guidance on avoiding Goodhart's Law traps like velocity targets and coverage goals. - Use Case: A VP of Engineering needs to present quarterly performance to the board. Use this Skill to build a trend-based executive dashboard showing DORA tier progression, connect metrics to business outcomes, and deflect requests for individual productivity surveillance. ## Quick Start Ask the AI to assess your team's current DORA metrics tier and design an improvement OKR for the weakest metric.

Frequently Asked Questions about engineering-metrics

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I measure engineering team performance with DORA metrics?▼

Track the four key metrics: deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time. Gather 2-3 months of pipeline data, calculate your tier against DORA benchmarks, and focus improvement on the single weakest metric per quarter.

What is the SPACE framework for developer productivity?▼

SPACE measures productivity across five dimensions: Satisfaction, Performance, Activity, Communication, and Efficiency. The core rule is to never use a single dimension alone — combine at least three to prevent gaming and get a balanced view of team health.

How do I instrument DORA metrics in Azure DevOps?▼

Use release pipeline run data for deployment frequency, AB# work item references to link commits through builds to releases for lead time, custom failed-deployment tags for change failure rate, and incident tracking integration for recovery time.

Why should I avoid using velocity as a performance target?▼

Velocity as a target triggers Goodhart's Law: teams inflate estimates, cherry-pick easy work, and sacrifice quality. Velocity is valid only as a team-internal sprint forecasting tool and is meaningless when compared across teams.

What is the difference between lead time and cycle time?▼

Cycle time measures active work start to completion, reflecting team efficiency. Lead time measures request or commit to completion, reflecting customer experience. Fast cycle time with slow lead time indicates a queue problem where work waits too long before starting.

When should I not use activity metrics like commit counts?▼

Never use activity metrics as individual performance targets — setting commit count goals causes developers to make tiny commits. Use them only as directional aggregate signals, and never show individual-level activity data to leadership.