maerortri This section provides a complete breakdown of how Sprint Health Analyzer calculates every metric visible in the app — from individual issue health scores to Agile metrics like velocity, burndown, and burnup.
Each value is derived directly from issue changelogs, sprint metadata, and Jira fields (e.g., Story Points).
🧪 Issue Health Score (0–1)
The Health Score summarizes how risky or unstable an issue was during its lifecycle in the sprint. It is calculated from four components:
Component | Weight | Source | Why it matters |
|---|---|---|---|
🕒 Cycle Time | 30% | Changelog (first → Done) | Long cycle time can indicate delivery delays |
⏳ Blocked Time Ratio | 30% | Changelog (Blocked status) | Time spent blocked reduces flow efficiency |
🔗 Critical Links % | 20% |
| More blocking/dependency links increase risk |
🔁 Status Jumps | 20% | Changelog | High jump count often signals rework or churn |
Formula
healthScore = 0.3 × normCycleTime + 0.3 × blockedRatio + 0.2 × criticalDependencyRatio + 0.2 × normStatusJumps + 0.1 buffer (soft bonus cap)
The final score is clipped at 1.0 maximum.
Normalization Details
Each component is normalized to [0–1] range:
Metric | Normalization Logic |
|---|---|
Cycle Time | 0 → 1 day, 1 → 7+ days. Normalized linearly in between. |
Blocked Ratio | Calculated as blocked duration / total lifecycle time |
Critical Links % | Ratio of |
Status Jumps | 0 → 2 or fewer jumps, 1 → 7+ jumps. Normalized linearly in between. |
🧭 Workflow Pattern
Each issue is classified with a visual Pattern tag, based on its behavior:
Pattern | Conditions |
|---|---|
🟢 stable | Low blockers, few jumps, low dependencies |
🟡 looping | >6 jumps + >20% blocked time |
🟣 hub | >50% blocking/dependency links |
🔴 unstable | >8 jumps, especially backward (regressions) |
🧮 Agile Metrics
These are calculated only when Agile mode is enabled and a sprint period is defined (via Sprint ID or manual date pickers).
📌 Velocity
Definition: Total story points completed (Done) within the sprint.
velocity = SUM(storyPoints for issues where doneAt ≤ sprintEnd)
📉 Burndown Chart
Definition: Daily view of remaining story points vs ideal linear burndown.
Line | Meaning |
|---|---|
Actual | Points remaining on each day (open or not yet done) |
Ideal | Perfect daily burn based on scope and sprint length |
remaining = totalScope - completedPointsByDay ideal = totalScope - (totalScope / (days - 1)) * dayIndex
📈 Burnup Chart
Definition: Daily view of cumulative work completed vs total scope.
Line | Meaning |
|---|---|
Completed | Cumulative points done by that day |
Total Scope | Points added up to that day |
completed = SUM(storyPoints where doneAt ≤ current day) totalScope = SUM(storyPoints for issues created ≤ current day)
🧾 Data Inputs Used
Data Source | Usage |
|---|---|
| For status changes, timestamps, cycle time |
| For dependency/blocking analysis |
| To determine final status |
| For tooltips & summaries |
| For velocity, burndown, burnup |
| Used as fallback end date |
📋 Summary of Metrics Used in Table View
Column | Description |
|---|---|
Health | Composite score from 4 metrics (0–1 scale) |
Jumps | Total number of status transitions |
Blocked % | % of lifecycle spent in blocked status |
Links % | % of links that are “blocks” or “depends on” |
Cycle Time | Duration from first status to final Done-type status |
Pattern | Derived from jump count, blockers, and dependency behavior |
🛡 Accuracy Depends On
Proper status naming (
Done,Blocked, etc.)Complete changelog access
Issues assigned to a sprint
Story Points filled in