If you want a pilot moving quickly, start with the GitHub App install, connect the right repos, and map one team. That sequence gets you to a usable first view without forcing a long setup project.
The goal of an engineering pilot is not to model everything on day one. It is to prove that your team can get scoped PR delivery metrics from GitHub, review them in context, and decide whether the data is useful for planning and staff meetings.
DeliveryCompass uses engineering intelligence for GitHub PR delivery to help managers coach teams with a clearer view of progress. Keep the pilot focused on GitHub PR metadata only so the scope stays clean and the results are easy to interpret.
Start with one team and one clear question
The fastest pilots are narrow. Pick one team, one repo set, and one question you want the pilot to answer. For example:
- Where is PR flow slowing down for this team?
- How are review and merge times trending over the last few weeks?
- Which repos should be included in a scoped team view?
Keeping the pilot focused makes it easier to validate the setup and easier for stakeholders to understand the first dashboard. If you are still deciding what to measure, choosing delivery metrics is a good place to align on the basics.
Install the GitHub App and connect the account
For a pilot, the first technical step is the GitHub App install. Use the read-only app install and OAuth connection so the team can grant access without changing GitHub workflows. Once connected, daily sync keeps the pilot current without manual exports.
If you want a setup checklist, follow the setup guide and keep the first pass simple. The fastest route is usually:
- Install the GitHub App on the GitHub organization.
- Connect the account through OAuth.
- Confirm the repos you want included in the pilot.
- Wait for the first sync to complete.
If the install does not behave as expected, use troubleshooting to check permissions, repository access, and sync timing.
Map teams and repos before you widen the pilot
Once the app is connected, map the pilot team to the right repositories. This step matters because scoped KPIs are only useful when the team boundary matches the work you actually want to review.
Start with a small repo set, confirm the team mapping, and then expand only if the pilot question requires it. The teams and repos guide explains how to keep the scope clean so the data stays easy to interpret.
In practice, this is where many pilots stall. People connect GitHub successfully, but then wait too long to define the team scope. A narrow mapping gets you to a usable view faster and reduces rework later.
Use the first dashboard to validate the pilot
After the first sync, review the overview dashboard for a quick read on team KPIs, trend charts, and the team performance table. This is the quickest way to tell whether the pilot data lines up with how the team actually works.
Then move to the team analytics chart grid for a more detailed look. The chart grid and drill-down views are helpful when you want to compare milestones, spot outliers, or check whether a change in process affected flow. If you need a walkthrough of the available views, see the dashboard docs and team analytics.
For teams that review work in staff meetings, the weekly summary can help surface what changed since the last check-in. The weekly summary page explains how attention callouts can make the conversation more focused.
Set expectations for the pilot review
A good pilot review answers three questions:
- Did the app connect cleanly and sync the expected repos?
- Is the team mapping accurate enough to trust the scoped KPIs?
- Do the charts and tables help the manager make a decision?
If the answer to any of these is no, that is useful. It tells you whether the issue is setup, scope, or the metric itself. For known boundaries and current product limits, check limitations and, for pilot-specific caveats, pilot limitations.
For teams that want a faster orientation after setup, the product tour can help users understand what they are looking at without making the pilot feel like a training project.
When the pilot is ready to expand
Expand only after the first team has a clean mapping and the dashboard answers the original question. Then you can add more repos, more teams, or a broader review cadence. The point is to scale from a working pilot, not to rescue a confusing one.
If you need a broader overview of the platform before expanding, review the documentation hub or the how it works page for a high-level summary of data flow and reporting.
FAQ
How long does a GitHub App engineering pilot setup usually take?
Most pilots can begin once the app is installed, OAuth is connected, and the first team and repo mapping is in place. The exact timing depends on how quickly the team confirms scope and access.
Do I need to map every repo before I can review the dashboard?
No. Start with the repos that match the pilot question. A narrower scope is often better for a first review because it keeps the results easier to interpret.
What should I check if the dashboard looks incomplete?
Confirm the GitHub App install, review repo access, and verify that the team mapping includes the repos you expected. If needed, compare your setup against troubleshooting.
Can I use the pilot for a staff meeting right away?
Yes, if the data scope is correct and the first sync has completed. The weekly summary and dashboard views are often enough to support an initial staff meeting review.
Where should I read next after the pilot is running?
Start with metrics if you want definitions, or GitHub metrics for managers if you want a broader management view.
When you are ready to start, begin the pilot onboarding here and follow the setup steps in order: connect GitHub, map the team, and review the first dashboard.