What is software delivery analytics, and how do you build it in Metabase?
Software delivery analytics turns the activity in your engineering tools — issue trackers, source control, CI/CD, incident, and support systems — into shared metrics about how work flows from idea to production. In Metabase, you build it by syncing those tools into a database, modeling a small set of clean tables, and standing up dashboards anyone can read.
What does software delivery analytics measure?
It measures flow, throughput, and quality across the delivery lifecycle, not individual output. The durable, leader-friendly questions are:
- Are we delivering faster or slower over time? (lead time, cycle time)
- How much are we shipping, and is it stable? (throughput, carryover)
- Where does work get stuck? (time in status, WIP, backlog aging)
- Is quality holding up? (bug aging, bug inflow vs. resolution, reopen rate)
- Are commitments realistic? (scope change, estimation accuracy)
Avoid vanity metrics (raw commit counts, lines of code, per-person leaderboards). They're easy to game and rarely change a decision.
Which data sources feed delivery analytics?
| Source category | Examples | What it contributes |
|---|---|---|
| Issue tracking / PM | Linear, Jira, GitHub Issues, Shortcut | Issues, cycles/sprints, statuses, throughput, backlog |
| Source control | GitHub, GitLab, Bitbucket | PR cycle time, review latency, merge frequency |
| CI/CD | GitHub Actions, CircleCI, Buildkite | Build/deploy frequency, failure rate |
| Incident | PagerDuty, Opsgenie, incident.io | MTTR, incident frequency, change-failure signal |
| Support | Zendesk, Intercom | Customer-reported bugs, support load |
Most teams start with issue tracking because it covers flow, throughput, backlog, and quality in one place. See the issue tracking overview for the shared model.
Which metrics matter most?
Define each one once and reuse the definition everywhere:
- Lead time — created → done. Captures total wait, including backlog.
- Cycle time — started → done. Active working time; report medians, not averages.
- Throughput — items completed per period. Pair counts with estimate points.
- Backlog aging — how long open work has been waiting.
- Bug aging — how long defects stay open, especially high-priority.
- Carryover & scope change — commitment realism (needs cycle/sprint history).
- DORA metrics — deployment frequency, lead time for changes, change failure rate, and time to restore (MTTR) from deploy and incident data.
How do you connect your tools to Metabase?
Two complementary routes, the same for every source tool:
- MCP route (AI-assisted) — pair a tool's MCP server with the Metabase MCP server for live, exploratory questions. Not for governed reporting or history.
- Pipeline route (warehouse-backed) — sync the tool into a database (Airbyte, Fivetran, dlt, or the API), model it, and build durable dashboards.
Tool-specific setup lives on the integration pages: Linear and Jira.
Which dashboards should you build first?
- Software delivery overview — the exec roll-up across flow, throughput, and quality.
- Sprint / cycle health — are we on track this iteration?
- Backlog aging and bug tracking — where work and defects pile up.