Skip to main content

Project Team Goals

Context & Objective

The objective of this semester is to identify metrics to accurately measure development velocity across all project teams, while ensuring that engineering effort translates directly into high-value features delivered to our nonprofit partners.

Success is defined not only by output (PRs, commits), but by cycle time, participation breadth, and impact on NPO-requested functionality.

This document follows the GQM (Goal–Question–Metric) framework to ensure metrics remain actionable and aligned with real outcomes.

Goals

G1. Accurately Measure Development Velocity per Team and per Developer

Identify metrics that accurately measure development velocity, and identify potential areas of improvement.

G2. Broaden Engineering Participation

Reduce bottlenecks caused by over-reliance on tech leads by increasing meaningful contributions from all developers.

G3. Maximize NPO Value Delivery

Prioritize and complete issues that directly map to NPO needs, reducing time-to-value.

G4. Improve Delivery Predictability

Enable project leads and NPOs to reliably anticipate feature delivery timelines.

Key Questions

Velocity & Flow
  • How quickly are teams converting issues into merged code?
  • Where are bottlenecks occurring (review, implementation, unclear requirements)?
Participation
  • Are contributions evenly distributed across team members?
  • Are non-tech-lead members actively reviewing and owning issues?
NPO Impact
  • How many completed issues directly correspond to NPO-requested features?
  • How long does it take to deliver an NPO-requested feature end-to-end?
  • How quickly are NPO-requested features transformed from identified needs into deployed, usable solutions for the partner?
Process Health
  • Are teams consistently engaging in standups and NPO syncs?
  • Are tasks being created and closed at a sustainable pace (number of created issues is closely similar to number of closed issues)?

Weekly Metrics

Velocity Metrics

  • Number of pull requests merged per team
  • Number of pull requests merged per developer
  • Average PR cycle time (open → merged)
  • Number of issues closed per team
  • Issue closure rate (closed / created per week)

Participation Metrics

  • Number of created pull requests per team
  • % of team members with ≥1 PR per week
  • Number of PRs reviewed by non-tech-lead members
  • Review participation distribution (to detect review bottlenecks).
  • Average time to give out a code review per team and per member
  • Estimate time to code an issue, and correlate it with task difficulty

NPO Value Metrics

  • Number of issues labeled as NPO-Feature closed per week
  • Average time to close NPO-Feature issues
  • NPO meeting summary → linked issues created
Process & Engagement Metrics
  • Standup meeting notes summary (auto-generated)
  • NPO meeting summary
  • Per-team attendance rate
  • Historical per-member attendance rate
  • % of attendees who pushed a commit or opened a PR that week

Automation

Velocity & Participation Automation
  • Weekly GitHub report per team:
    • PRs merged
    • PRs opened
    • Issues created / closed
    • Cycle time averages
  • Per-developer activity summary sent to project leads
Accountability & Alerts
  • Alarms for team members with no PR activity for > 2 weeks
  • Alerts for:
    • PRs open > 7 days
    • Issues stalled with no activity > 10 days
  • Team-level alerts when issue creation outpaces closures
  • Team-level alerts when no new issues are created
NPO Value Tracking

Expected Outcomes

By the end of Spring 2026, this framework should result in:

  • Faster, more predictable feature delivery
  • Higher contribution rates from non-lead developers
  • Clear, measurable alignment between engineering output and NPO impact
  • Reduced burnout and review bottlenecks
  • Data-driven project retrospectives instead of anecdotal feedback

No Comments
Back to top