If your team KPIs look noisy, the problem is often scope, not the metric. The fastest way to get useful delivery data in GitHub is to map the right teams and repos first, then measure only the work that belongs to that scope.
For most engineering managers, that means starting with a small, explicit mapping: one team, the repos they truly own, and the KPI set you want to review consistently. DeliveryCompass supports teams and repos mapping for scoped KPIs, so your dashboard and trend charts reflect the right slice of delivery activity.
Start with the scope you actually manage
Before you map anything, write down the management boundary. Ask three simple questions:
- Which team is accountable for the KPI?
- Which GitHub repos should count toward that team?
- Are there shared repos or service repos that need special handling?
This matters because a broad org-wide rollup often mixes unrelated work streams. A scoped setup gives you cleaner team performance data in the overview dashboard and better signal in the team analytics chart grid.
Map teams to repos before you compare KPIs
A common mistake is comparing teams before the mapping is stable. If one team owns three repos and another owns twelve, the numbers may be valid but still hard to interpret.
Use the mapping step to define ownership first:
- List the team name as it appears in your operating model.
- Add the GitHub repos the team owns day to day.
- Exclude repos that only receive occasional changes from outside the team.
- Document shared ownership where needed so reviews stay consistent.
DeliveryCompass uses this mapping to scope KPIs to the selected team and repo set. That makes trend charts, table views, and drill-downs much easier to read when you review delivery in staff meetings. It is a practical way to apply engineering intelligence for GitHub PR delivery while keeping the focus on team-owned work.
Pick KPIs that match the mapped scope
Once the mapping is in place, choose metrics that answer a management question. For scoped GitHub delivery, the most useful views usually come from lead time, review flow, and throughput patterns.
When you are deciding what to track, use the metric guidance in choosing delivery metrics and the definitions in metrics. If your team is new to GitHub-based measurement, the GitHub metrics for managers guide is a good starting point.
A practical rule: if a KPI cannot be explained from the mapped repos and the team’s operating cadence, it is probably too broad for the first pass.
Handle shared repos and edge cases explicitly
Shared repos are where scoped KPI setups usually get messy. The fix is not to ignore them; it is to decide how they count.
Use one of these approaches:
- Owned repo: count the repo only for the primary team.
- Shared service repo: include it only if the team is accountable for its delivery flow.
- Reference repo: exclude it from KPIs if the team only contributes occasionally.
If you are still deciding whether a repo belongs in the pilot, check the current boundaries and known constraints in limitations. For setup-specific details, setup and how it works explain how mapping feeds the dashboard.
Review the mapping in the dashboard, not just in a spreadsheet
Spreadsheets are fine for planning, but they are easy to drift. Once the mapping is active, validate it in the product view where the metrics actually appear.
Use the dashboard to confirm the team KPIs are scoped correctly, then open team analytics to inspect trends and milestones. If you want a structured way to compare changes over time, chart milestones can help you explain what shifted and when.
For teams that want a weekly operating rhythm, the weekly summary gives a compact view you can bring into staff meetings without rebuilding the data by hand.
Use pilot setup to validate scope before expanding
If you are introducing GitHub metrics for the first time, start small. A pilot is the easiest way to confirm that the team-to-repo mapping matches real ownership.
In a pilot, you can validate three things quickly:
- The right repos are included.
- The dashboard reflects the intended team scope.
- The KPI trends make sense to the manager and the team.
If the pilot scope still feels unclear, review faq for common setup questions, and revisit troubleshooting if a repo does not appear as expected. The notes in limitations for pilot are also worth checking before you expand to more teams.
FAQ
How many repos should I map to one team?
Start with the repos the team truly owns and can influence directly. If the team depends on many shared repos, keep the first mapping tight so the KPI trends stay readable.
Should I include every repo where the team makes occasional PRs?
Usually no. Occasional contributions can add noise without improving the management signal. Include only repos that reflect the team’s normal delivery responsibility.
What if two teams both work in the same repo?
Decide which team owns the delivery KPI for that repo, or split the scope only if your operating model is already clear about that ownership. Ambiguous shared repos are a common source of misleading rollups.
Can I change the mapping after the pilot starts?
Yes. In fact, pilot feedback is often the best time to correct scope. Just keep a clear record of what changed so the trend charts are interpreted correctly.
Where should I send managers who want the broad setup picture?
Point them to product tour for a quick walkthrough, then use about and docs for the full reference.
If you are setting this up for your own team, start the pilot at /app/onboarding and map just one team and its repos first. That gives you a clean baseline before you expand to more scopes.