๐ How We Calculate Scores and Agile Metrics
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