Team & Project Health
Sprint health, code review, quality, and team workload for the SPARK pilot.
FiltersTeam:SPARKSprint:Active
——————
——————
——————
——————
Sprint HealthMeasures how well the team plans and executes each sprint — covering delivery rate, work added late, incomplete issues, and unplanned interruptions.Calculated: Four sub-metrics derived from Jira sprint data: predictability, throughput, carryover rate, and unplanned work ratio. Each is computed at sprint close using issue status and changelog events.
Live snapshot of the active sprint and the trend across the last six sprints.
PredictabilityHow closely the team delivered what it committed to at sprint start.Calculated: Delivered points ÷ committed points at sprint start, capped at 150%. Elite ≥85%, High ≥70%.
—
no active sprint data
Throughput (this sprint)Total story points completed in the sprint.Calculated: Sum of story points for all issues marked done by sprint end. Issues with no estimate count as 1 pt.
—
no data
CarryoverShare of sprint issues that were not finished and rolled into the next sprint.Calculated: Incomplete issues at sprint end ÷ total issues in sprint.
—
no data
Unplanned workShare of issues that were added after sprint start or classified as interrupts (bugs, hotfixes).Calculated: Unplanned issues ÷ total issues. An issue is unplanned if added mid-sprint, or is a Bug / has a hotfix, incident, or interrupt label.
—
no data
Predictability — last 6 sprintsHow closely the team delivered what it committed to at sprint start, shown across the last 6 sprints.Calculated: Each bar shows committed points (light blue) vs delivered points (green). Predictability = delivered ÷ committed, capped at 150%. Issues with no estimate count as 1 pt.
Story points: committed vs delivered (story-point default = 1)
Scope churnHow much the sprint scope changed after it started. High churn signals poor upfront planning or frequent interruptions.Calculated: Issues added after sprint start (amber) vs issues removed (red). Source: Jira changelog events where an issue's sprint field changed after the sprint start date.
Issues added vs removed mid-sprint
Carryover rateShare of issues that were not completed in the sprint and rolled into the next one. A rising trend signals the team is consistently over-committing.Calculated: Incomplete issues at sprint end ÷ total issues in sprint. An issue is incomplete if its status was not Done/Closed when the sprint closed.
% of sprint issues rolling over
Unplanned workShare of sprint work that was not planned at sprint start. Persistent high unplanned work erodes predictability and signals reactive fire-fighting.Calculated: Unplanned issues ÷ total sprint issues. An issue is unplanned if it was added mid-sprint, or is a Bug / carries a hotfix, incident, or interrupt label.
Hotfixes + interrupts as % of sprint
Code Review Health
PR flow + reviewer concentration over the last 12 weeks.
PR size — weekly trend (last 12 weeks)
Stacked weekly counts by size bucket
Merge wait — weekly trend (last 12 weeks)
Per-week typical and tail wait time
WIP trendWork-in-progress signal showing how many pull requests are being opened versus closed each day. A sustained gap where opened outpaces closed indicates the team is accumulating unmerged work.Calculated: Daily counts of PRs opened and closed across all team repos. 'Opened' = created_at date; 'Closed' = merged_at or closed_at date. Sourced from aica-prod-pull-requests.
Team-wide PRs opened vs closed per day · last 84 days
Quality & IncidentsTracks production stability through three lenses: how often releases cause incidents (CFR), how quickly the team recovers from them (MTTR), and how many bugs are being shipped per sprint (defect rate).Calculated: Incidents are SPARK Bug issues with priority Highest/High or labelled incident/production-incident/prod-incident. CFR and MTTR are derived from Jira issue data; defect rate from sprint snapshots.
Defects, change failures, and recovery.
CFR — last 12 weeksThe proportion of deployments each week that caused a production incident. A rising trend signals that releases are becoming less stable.Calculated: Incident count ÷ deployment count per calendar week. Incidents are high-priority Jira Bugs or issues with an incident label. Deployments are detected from branch merges, GitHub Deployments API, and workflow runs.
Change failure rate per week
MTTR by priorityHow long it takes to resolve incidents, broken down by Jira priority. Taller bars for Highest/High mean critical incidents are taking too long to fix.Calculated: Median (P50) hours from incident created_at to resolved_at (status → Done/Closed), grouped by priority. Only incidents matching the team's incident filter are included.
Median resolution time per incident priority
Defect rate by sprintThe ratio of bugs to stories completed each sprint. A growing bug proportion suggests quality is declining — the team is shipping more defects relative to features.Calculated: Per sprint: bug count (red) and story count (green) of completed issues. Both stacked to show total sprint output. Issues with type Bug are counted as defects.
Bugs vs stories shipped per sprint