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