If your GitHub metrics feel too broad, the fix is usually not a new chart. It is better scope. When you map the right teams and repos to the right KPI set, the numbers stop mixing unrelated work and start reflecting how each team actually delivers.
That is the practical value of GitHub teams repos KPI mapping: clearer team-level trends, cleaner reviews in staff meetings, and less time explaining why a dashboard looks “off.” DeliveryCompass supports teams and repos mapping for scoped KPIs, so you can look at performance by the boundaries your org already uses.
engineering intelligence for GitHub PR delivery
Why scoped KPI mapping matters
Metrics only help when the unit you measure matches the unit you manage. If one dashboard combines repos from multiple teams, you can end up with lead time, review time, or throughput that hides local bottlenecks.
Scoped KPI mapping helps you:
- compare one team against its own baseline instead of the whole org
- separate platform work from product work
- avoid blending active repos with legacy or maintenance repos
- make staff meeting discussions more specific and more useful
For a broader view of what DeliveryCompass measures, see /docs/metrics and /docs/choosing-delivery-metrics.
Start with the team boundary, then map repos
The easiest setup mistake is to begin with every repo and try to sort it out later. A better approach is to define the team first, then assign the repos that reflect that team’s actual delivery surface.
Use the team as the KPI scope
Choose the team you want to review. That might be a product squad, a platform group, or an enablement team. The point is to keep the KPI scope aligned with the people responsible for the work.
Map the repos that belong in that scope
Include the repos that represent the team’s delivery flow. Exclude repos that are owned elsewhere, are shared across several groups, or would distort the team’s typical PR activity.
For setup details, the starting point is /docs/teams-and-repos, plus /docs/setup if you are still configuring your account.
Keep scoped KPIs useful by avoiding mixed signals
Once teams and repos are mapped, the main job is consistency. Scoped KPIs break down when the mapping changes every week or when one repo is counted in more than one place without a clear reason.
Watch for these common issues:
- Shared repos: if several teams contribute, decide whether the repo belongs in one scope or should stay out of team-level KPI views
- Special-case repos: maintenance, prototypes, and migration repos often need separate treatment
- Changing ownership: when a repo moves teams, update the mapping so the trend line stays meaningful
- Temporary work: short-lived work can create spikes that do not represent normal delivery
If you want to understand where scoped data can still have limits, review /docs/limitations.
Use scoped mapping to make team dashboards easier to read
DeliveryCompass includes an overview dashboard with team KPIs, trend charts, and a team performance table. Once your team and repo mapping is clean, those views become much easier to interpret because each chart reflects a narrower, more relevant slice of work.
That also makes drill-downs more practical. A manager can move from the overview dashboard to team analytics, then inspect chart milestones without first untangling unrelated repositories.
Helpful references:
Review mapping before staff meetings and monthly check-ins
Scoped KPIs are most useful when they support decisions. Before a staff meeting, review whether the team scope still matches the repos people are discussing. That keeps the conversation grounded in the work that team actually owns.
A simple routine works well:
- Confirm the team and repo scope
- Check the trend chart for the selected KPI set
- Look for milestones or changes that explain movement
- Use the weekly summary to spot attention items before the meeting
If you run recurring reviews, these pages can help you set the cadence: /docs/weekly-summary and /docs/guides/staff-meeting-metrics.
Keep the mapping current as ownership changes
Team structure is not static. Repos get transferred, teams split, and some work becomes shared. The KPI mapping should change when the ownership model changes, not weeks later.
A low-friction maintenance habit is to review team and repo scope whenever:
- a repo changes ownership
- a team’s charter changes
- a new service or product area launches
- a legacy repo should no longer count toward a team KPI
If you are still deciding what to include in your review process, the guides in /docs/guides/github-metrics-for-managers and /docs/guides/pr-flow-engineering-teams are a useful companion.
FAQ
Should every GitHub repo be mapped to a team?
No. Map repos that belong in the KPI scope for a specific team. Shared, temporary, or out-of-scope repos can make team metrics harder to interpret.
What if one repo supports more than one team?
Decide whether that repo should live in one team scope, stay outside team-level KPIs, or be reviewed separately. The goal is a clean ownership model, not forcing every repo into a dashboard.
Can I change the mapping later?
Yes. Mapping should follow your actual team structure. When ownership changes, update the scope so trend lines continue to reflect the right work.
Why do scoped KPIs sometimes look different from org-wide metrics?
Because they are measuring a narrower slice of work. That difference is usually a sign the mapping is working, not a problem with the data.
Where should I start if I am setting this up for the first time?
Start with /docs/teams-and-repos, then confirm your overall setup in /docs/setup.
If you want to see how scoped KPIs fit into your delivery workflow, start a workspace at /app/onboarding.