No Jira Access? Here's What Your Git Data Already Knows

You need to report on engineering progress, but you don't have access to Jira. Maybe it's owned by another team, maybe you're in a different org, or maybe your team just uses GitHub for everything. Good news: your Git data tells a compelling progress story on its own.

This guide shows you how to track and report engineering progress using pull request data, deployment frequency, and repository metrics—no project management tool required.

When You Don't Have Access to the PM Tool

Common Scenarios

Many engineering managers find themselves without access to traditional progress tracking:

• Embedded in client organization: Contractors and consultants often can't access the client's PM tools
• Cross-functional projects: Engineering may use different tools than product/PM
• Startup without PM tooling: Small teams that haven't set up formal project management
• Open source projects: No centralized PM tool, just GitHub issues
• Agency work: Each client has different tools, need consistent reporting

Why Git Data Works

Git data has advantages over PM tool data for progress tracking:

• Can't be gamed: Unlike story points, merged PRs represent actual work done
• Automatic: No need to update tickets—data captured as part of normal workflow
• Granular: See exactly what code shipped, not just ticket status changes
• Universal: Every engineering team uses Git, regardless of PM tools

PRs Merged as a Progress Proxy

Why PRs Are a Good Progress Indicator

Pull requests represent completed, reviewed, and shipped work:

• Completion signal: A merged PR means work is done, not "in progress"
• Quality gate: Merged PRs have passed code review
• Deployment proxy: Merged usually means deployed (or ready to deploy)
• Team effort: PRs show collaboration (author + reviewers)

Tracking PR Velocity

PR Breakdown by Type

Not all PRs are equal. Break down by type if possible:

• Feature PRs: New functionality (progress on roadmap)
• Bug fix PRs: Stability work (maintaining quality)
• Refactoring PRs: Technical investment (enabling future speed)
• Documentation PRs: Knowledge capture (team efficiency)

You can approximate this by repository, file path patterns, or PR title conventions.

Repository Breakdown for Project-Level Tracking

Mapping Repositories to Projects

If your repositories map to projects or features, you can track project-level progress through repository metrics:

Repository Metrics to Track

For each project-repository, track:

• PRs merged: Volume of completed work
• Contributors: Team members actively working on it
• Cycle time: How quickly work moves through
• Churn: Is work being redone (possible scope issues)?

Deployment Frequency as Delivery Cadence

What Deployment Frequency Shows

Deployment frequency is one of the DORA metrics and indicates how often you're delivering value:

• High frequency (daily+): Continuous delivery, small batches, fast feedback
• Medium frequency (weekly): Regular releases, predictable cadence
• Low frequency (monthly+): Batched releases, longer feedback cycles

Using Deployment Frequency in Reports

Building Weekly Status Reports from Git Data

Report Structure

Data Sources for Each Section

• Summary metrics: CodePulse Dashboard, weekly period
• Progress by project: Filter by repository, count PRs
• Highlights: Review merged PRs for significant completions
• Blockers: Open PRs with long cycle time, or external dependencies

Automating the Report

You can partially automate status report generation:

1. Metrics section: Export from CodePulse Dashboard
2. Project breakdown: Export per-repository metrics
3. Highlights/blockers: Manual curation based on PR titles
4. Next week: Based on open PRs and planned work

See our Weekly Engineering Status Report Template for more detailed formatting guidance.

Limitations and When You Need More

What Git Data Can't Tell You

Be honest about the limitations of Git-only tracking:

• Business value mapping: PRs don't directly map to user stories or business outcomes
• Roadmap progress: Without tickets, you can't show "Feature X is 60% complete"
• Priority alignment: Can't tell if work aligns with stated priorities
• Scope changes: No visibility into requirement changes or scope creep
• Estimation accuracy: Can't compare planned vs actual without estimates

Supplementing Git Data

To address gaps, consider lightweight additions:

When to Invest in PM Tooling

Consider adding a PM tool when:

• Stakeholder needs: Executives need business-level roadmap visibility
• Cross-team coordination: Multiple teams need to coordinate dependencies
• Estimation culture: Team wants to improve estimation and planning
• Compliance requirements: Need audit trail of requirement-to-code tracing

Making Git-Based Progress Tracking Work

Set Expectations

When reporting progress from Git data alone, be clear about what you're measuring:

• You can say: "The team shipped 23 PRs this week, 8% more than last week"
• You can't say: "Feature X is 75% complete" (without additional context)
• You can say: "The checkout repository received 8 PRs, the most of any project"
• You can't say: "Checkout is on track for the April deadline" (without knowing scope)

Build Narrative Around the Data

Data alone isn't enough—add context and narrative:

For more on communicating engineering progress, see our guides on Board-Ready Engineering Metrics and Engineering Metrics Dashboard.