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

Auto-link NPO meeting notes

Weekly report:

“NPO value delivered this week” (Send to NPO as weekly update, LinkedIn)

Issues closed that directly map to partner requests

End-of-semester summary:

Features shipped per NPO

Average time-to-value per project

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