# 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