Patterns & Health Score
A complete guide to understanding Delivery Doctor's metrics, scores, and pattern detection.
Health Score
The Health Score is a single number from 0 to 100 that represents your project's overall delivery health. It gives you a quick, at-a-glance understanding of how smoothly work is flowing through your team.
How It's Displayed
- A semicircle gauge (speedometer-style) with a letter grade (A–F) in the center, color-coded by severity.
- Click the gauge to reveal a 7-day trend sparkline so you can see whether things are improving or declining.
- An orange dot appears next to "Last Refresh" when the data is older than 1 hour, reminding you to refresh.
Formula
The score starts at 100 and deducts points for each active pattern:
Score = 100 - (10 x CRITICAL patterns) - (3 x WARNING patterns)
Minimum: 0Example: 2 critical patterns + 5 warning patterns = 100 − 20 − 15 = 65 (Grade C).
Grade Scale
| Grade | Score | Status | Meaning |
|---|---|---|---|
| A | 85–100 | Excellent | Healthy delivery flow with minimal issues |
| B | 70–84 | Good | Generally healthy with some areas for improvement |
| C | 55–69 | Needs Attention | Multiple issues affecting delivery |
| D | 40–54 | Poor | Significant bottlenecks impacting the team |
| F | 0–39 | Critical | Severe delivery problems requiring immediate action |
Stagnation (Days in Status)
Stagnation measures how long an issue has been sitting in its current status without meaningful progress. It is calculated from the last time the issue entered its current status (not the generic "updated" timestamp).
An issue might be updated by adding comments or editing fields, but if it hasn't moved to a new status, it's still stagnating. Using the changelog transition timestamp gives a much more accurate picture of actual flow.
Adaptive Baseline
Instead of using fixed thresholds, Delivery Doctor calculates thresholds based on your team's own data. It uses the 85th percentile (p85) of cycle times from issues completed in the past 90 days.
WARNING = 1x baseline (or 5 days default)
CRITICAL = 2x baseline (or 10 days default)Fallback logic (when not enough historical data is available):
- Type + Status specific — e.g., "Bug in Code Review" uses the baseline for that exact combination.
- Status only — e.g., "Code Review" baseline for any issue type.
- Global defaults — 5 days for warning, 10 days for critical.
See Smart Features section below →
Patterns Reference
Delivery Doctor detects 8 pattern types. Each pattern has its own detection logic and thresholds based on industry best practices. Below is a complete reference for every pattern.
Pattern 1: Aging Work
What it detects: Issues stuck in the same status for too long. Uses the issue changelog to find when the issue last entered its current status.
Thresholds:
- Warning ≥ 1× p85 baseline
- Critical ≥ 2× p85 baseline
Fallback defaults:
- In Progress: 5 days
- Done: 2 days
- To Do: 3 days
Why these thresholds: Research shows that issues stalled beyond the team's baseline often indicate blockers, unclear requirements, or resource conflicts.
A bug in "In Code Review" for 12 days. Your team's p85 for code review is 4 days → Critical (12 > 8 = 2× baseline).
Pattern 2: Team Pulse
What it detects: Two sub-patterns:
- Overloaded People — team members juggling too many active contexts, causing context-switching overhead.
- Unassigned Tasks — "In Progress" issues with no assignee (nobody is responsible).
Thresholds — Overloaded:
- Warning ≥ 3 contexts per person
- Critical ≥ 5 contexts per person
Thresholds — Unassigned:
- Critical Any "In Progress" issue without an assignee
Smart grouping: Subtasks under the same parent issue count as a single context, so they don't inflate the count.
Why: Context switching costs roughly 40% of productivity. The "Rule of 3" tells us that humans can effectively manage 2–3 active threads at once. Beyond that, quality and speed drop sharply.
Alice has 6 unrelated stories "In Progress" → Critical.
Pattern 3: Estimation Variance
What it detects: Time logged on an issue is approaching or exceeding the original estimate.
Thresholds:
- Warning ≥ 90% of estimate used
- Critical ≥ 150% of estimate used
Why: At 90%, the team is nearly out of budgeted time. At 150%, there is a significant overrun that likely needs re-scoping or stakeholder conversation.
An issue with an 8-hour estimate has 12 hours logged (150%) → Critical.
This pattern shows "Unavailable" if no issues in the current view have time estimates configured.
Pattern 4: Aging Impediments
What it detects: Issues that have been blocked for an extended period. Uses the Jira impediment flag or a blocked status category.
Thresholds:
- Warning ≥ 3 calendar days blocked
- Critical ≥ 7 calendar days blocked
Note: These are calendar hours, not business hours. Weekends count toward the total.
Why: After 3 days blocked, the impact on downstream work multiplies. After 7 days, the issue is clearly being neglected and needs escalation.
An issue flagged as blocked 5 days ago → Warning. After 7 days → Critical.
Pattern 5: On-Time Delivery
What it detects: Issues with approaching due dates that are not yet complete.
Thresholds:
- Warning ≤ 3 days until due (5 days on Thursday/Friday)
- Critical Overdue, ≤ 1 day until due, or not started within warning window
Auto-escalation: Issues still in "To Do" within the warning window are automatically escalated to Critical because there is not enough time left to complete them.
Thursday Rule: On Thursday and Friday, the warning window expands from 3 to 5 days to account for the weekend. Learn more about the Thursday Rule →
It's Friday and a story due next Wednesday hasn't started yet → Critical.
Pattern 6: Rework
What it detects: Reopened issues or status ping-pong (issues bouncing back and forth between statuses).
Thresholds:
- Warning 1 reopen from Done OR 2–3 status loops
- Critical 2+ reopens from Done OR 4+ status loops
Why: Reopening means the issue was marked complete prematurely. Ping-ponging between statuses usually signals unclear requirements or miscommunication between roles.
A story moved to Done then back to In Progress → Warning. If it happens twice → Critical.
A 5-minute grace period is applied to ignore accidental status changes (e.g., clicking "Done" by mistake and immediately reverting).
Pattern 7: Backlog Rot
What it detects: Issues sitting in the backlog (To Do) for an extended time since creation, without ever being started.
Thresholds:
- Warning ≥ 90 days since created
- Critical ≥ 180 days since created
Severity: Info — this pattern is informational only. It does not affect the Health Score as heavily as other patterns.
Why: Items older than 90 days are likely outdated and may no longer align with current priorities. At 180 days, they are almost certainly obsolete and should be reviewed or closed.
15 stories created 6 months ago that have never been started.
Pattern 8: Wasted Efforts
What it detects: Cancelled issues that had significant time invested before cancellation. Tracked resolutions include: Won't Do, Duplicate, Cannot Reproduce, and Declined.
Thresholds:
- Warning ≥ 4 hours logged on a cancelled issue
- Critical ≥ 16 hours logged on a cancelled issue
Analysis period: Last 14 days.
Why: Cancelled work after significant investment is a sunk cost. Frequent occurrences indicate systemic problems like unclear requirements, poor prioritization, or late decision-making.
20 hours logged on a feature that was cancelled as "Won't Do" → Critical.
Quick Reference
All 8 patterns at a glance:
| Pattern | Category | Warning | Critical |
|---|---|---|---|
| Aging Work | Flow | ≥ 1× p85 baseline | ≥ 2× p85 baseline |
| Aging Impediments | Flow | ≥ 3 calendar days | ≥ 7 calendar days |
| Team Pulse | Flow | 3–4 contexts/person | 5+ contexts OR unassigned |
| Rework | Risks | 1 reopen / 2–3 loops | 2+ reopens / 4+ loops |
| On-Time Delivery | Risks | ≤ 3d (5d on Thu/Fri) | Overdue / ≤ 1d / not started |
| Estimation Variance | Risks | ≥ 90% estimate used | ≥ 150% estimate used |
| Wasted Efforts | Value | ≥ 4h logged | ≥ 16h logged |
| Backlog Rot | Hygiene | ≥ 90d since created | ≥ 180d since created |
Smart Features
Delivery Doctor includes several intelligent behaviours that work automatically to improve accuracy and reduce noise.
Thursday Rule
On Thursday and Friday, the due-date warning window expands from 3 to 5 days so that deadlines falling after the weekend are surfaced before you leave for the week.
Adaptive Baseline
Stagnation thresholds are calculated from your team’s real data — specifically the 85th-percentile (p85) of cycle times from issues completed in the past 90 days. This means thresholds automatically adapt to your team’s pace instead of relying on fixed values.
Pattern Filter
Use the filter icon in the TopBar to temporarily hide patterns you don’t need right now. The filter is session-level only and resets when you reload the page.
Highlander Deduplication
Each ticket appears as one row with the highest-priority badge shown. Hover to see all detected patterns for that issue. Snoozing dismisses every pattern for the ticket at once.