Engineering Health Dashboard

The Engineering Health dashboard helps engineering leaders monitor and improve team health over time. It combines human review activity, weekend activity, work-item data from your project management tool, and pull request maturity to show how work is distributed across people, how much developers are juggling at once, and where delivery slows down enough to become frustrating.

Use this dashboard to understand whether review load is concentrated on a few people, whether work is spilling into weekends, how much of the team's completed work is unplanned or high priority, and how review-ready pull requests are when they merge. The dashboard is available to every customer with Metrics Builder enabled.

Open the dashboard

1. In LinearB, select Metrics.
2. Open Metrics Builder.
3. Under LinearB Catalog, select Engineering Health.
4. Set the Date Range and the teams you want to analyze.

Most widgets apply the selected date range and team scope. The header metric cards also show the trend compared with the previous period. Weekly charts include the first and last weeks of the range even when they are partial weeks.

Data requirements

The dashboard draws on two data sources:

• Git data: Powers the review load, weekend activity, context switch, and PR maturity widgets. Context switch widgets only count activity on branches that are linked to a work item.
• Project management data: Powers the planned vs. unplanned, priority, tickets in progress, and time-in-state widgets.

Important: The planned vs. unplanned widgets are calculated from closed Scrum sprints and are not filtered by the selected teams. Planned vs. Unplanned Completion can be scoped by board, and Unplanned Work Share always covers the whole organization. Teams that work in Kanban do not populate these widgets.

Note: Weekend activity is determined by your organization's working days setting. Any day outside the configured working days counts as a weekend day.

Dashboard metrics

The header metric cards summarize the dashboard. Each card shows the trend compared with the previous period.

Interpret the dashboard sections

Below the header cards, the dashboard is organized into three sections. Each section answers one question about team health.

Workload Balance & Sustainability

This section shows how review work is distributed, whether a small group is overloaded, and whether delivery work is spilling into weekends. All review widgets count human reviews only.

• Reviewers by Weekly Review Load: The number of developers in each band of weekly reviews. Bands are calculated from the distribution of your reviewers for the selected period, so the band labels change with your data. Read the band labels to see how far apart the lightest and heaviest reviewers are.
• Weekly Review Load by Group: The average number of reviews per reviewer each week, for the top 20% of reviewers and for the remaining 80%. The cohorts are the same as in Reviewer Imbalance. A widening gap between the two lines means review work is concentrating.
• Active Developers on Weekends: The number of developers with Git activity on weekend days, by week. Look for repeated peaks rather than a single spike around a release.

Cognitive Load & Work Pressure

This section shows how much work developers manage at once, how much of it is unplanned or high priority, and where cognitive load is increasing.

• Planned vs. Unplanned Completion: Work items from Scrum sprints that closed in the selected period, split into planned and unplanned, and into completed and uncompleted. A lower completion rate on planned work means incoming demand is displacing the plan.
• Unplanned Work Share: The percentage of completed sprint items that were added after the sprint started, across all Scrum sprints in the organization that closed in the selected period.
• High Priority Share: The percentage of work items completed in the selected period whose priority is High or Urgent.
• Urgent Work Items %: The priority mix of work items completed each week (Low, Normal, High, Urgent). Priorities that LinearB cannot map are counted as Normal. A growing Urgent band means more work is arriving as an escalation.
• Multitask Distribution: The number of developers in each band of peak daily work items, using the same per-developer value as Context Switch. Bands are calculated from the distribution of your developers, so the labels change with your data. Developers in the right-hand band hit the highest peaks.
• Tickets in Progress per Developer: The number of distinct work items in progress each week, alongside the number of developers with Git activity that week. A work item counts as in progress from the day it first enters an in-progress state until the day it first reaches Done. Work items rising while active developers stay flat means load per developer is increasing.

Review Readiness & Development Friction

This section shows whether work is ready for review and where it slows down during delivery.

• PR Maturity Trend: The number of merged pull requests each week in each PR maturity band: High (80 and above), Medium (50 to 79), Low (30 to 49), and Very low (below 30). A shrinking High band indicates pull requests arriving less review-ready.
• Development Drag: The average time work items spend in each in-progress workflow state, measured from entering the state until the next in-progress state, ranked from longest to shortest. Time in the final state before Done is not included. The longest bars show where work gets stuck.

Hover over a point to see the values for that interval. Look for sustained movement across several intervals instead of treating one point as a trend.

View supporting data

Select a metric card to open its supporting data, when drilldown is available. A drilldown can include:

• The query used to retrieve the result.
• A plain-language explanation of the result.
• The contributing developers, pull requests, or work items.
• Pagination controls for reviewing additional rows.

For example, the Reviewer Imbalance drilldown shows the average weekly reviews for the top 20% and for the remaining 80% of reviewers. A pull request metric drilldown can list the pull requests included in the result and provide links to the source repository.

Best practices

• Connect your project management tool before relying on the Cognitive Load & Work Pressure and Development Drag widgets, and link branches to work items so the context switch widgets can see them.
• Confirm that your working days setting is correct before reading the weekend widgets.
• Use a date range long enough to reduce the effect of short-term fluctuations, and read the partial first and last weeks of weekly charts with care.
• Treat Planned vs. Unplanned Completion and Unplanned Work Share as organization-level or board-level views, not team views.
• Review workload, pressure, and readiness together; no single metric provides a complete picture of team health.
• Use drilldowns to validate which developers, pull requests, or work items contributed to a result before discussing it with a team.
• Treat the dashboard as a conversation starter for team leads and directors, not as an individual performance measure.

Related articles

• AI ROI Dashboard
• Metrics Builder
• PR Maturity Metric
• Reviews Metric
• Wellness Workload in Developer Coaching
• Understanding Metrics Dashboards in LinearB