Engineering Performance Report

PI 9 Analysis

PI 9 deep-dive with PI 5-8 as trend context. Five teams evaluated against defined targets across agile execution, DORA deployment frequency, and developer activity. Three storylines drive this PI: Mobile's reversal, Web's regression, and a step change in planning discipline for Data and Fusion.

Focus PI PI 9 (4 Feb 2026 to 29 Apr 2026)

Trend Window PI 5 to PI 9

Teams Cloud · Data · Fusion · Mobile · Web

Data Sources Jira · Git · Deployments

Quick Diagnosis

Team Status Dashboard (PI 9)

RAG status per team across six dimensions. Green = at or above target / improving meaningfully. Amber = below target but stable or marginally moving. Red = critical underperformance or sharp regression. Grey = no data.

Team	Completion	Sprint Goals	Creep Control	Bug Throughput	MR Velocity	Deployment
Cloud	54%▲ +2pp	83%15/18	26%▼ +4pp	21▼ ×2.1	466▲ +41%	5▲ +1
Data	50%▲ +2pp	86%6/7	9%▲ -24pp	10flat	277▲ +423%	—no data
Fusion	54%▲ +6pp	100%18/18	12%▲ -27pp	5▲ -7	104▲ +104%	—no data
Mobile	66%▲ +16pp	48%12/25	32%▲ -17pp	90▲ -26	646▲ +62%	—no data
Web	60%▼ -29pp	88%7/8	27%▼ +16pp	4▲ -4	137▲ +30%	3▼ -2

Arrows indicate direction vs PI 8. ▲ = improving (good direction). ▼ = regressing (bad direction). For creep and bugs, lower is better, so "▲ -24pp" means a 24-point reduction. Read across each row for one-team-at-a-glance, or down each column to compare teams on a single dimension.

Executive View

Completion Ratio Heatmap (PI 5 to PI 9)

Completion Ratio (% of committed points delivered)

Target ≥ 80% · Green = on target · Yellow = 60 to 79% · Red = below 60% · PI 9 column outlined

* No team hit the 80% target in PI 9. First time this has happened in the trend window.

Completion Ratio Trend (all teams)

PI-level commit_done / commitment

80% target

Creep Ratio Trend (all teams)

Unplanned work as % of planned commitment

20% ceiling

PI 9 Snapshot

Completion ratio per team with delta vs PI 8

Cloud

54.1%

Completion

▲ 2pp vs PI8

Data

50.5%

Completion

▲ 2pp vs PI8

Fusion

54.0%

Completion

▲ 6pp vs PI8

Mobile

66.2%

Completion

▲ 16pp vs PI8

Web

59.9%

Completion

▼ 29pp vs PI8

Sprint Goals

Goal-Setting and Goal Achievement

PI 9 is the first PI with structured sprint goal data captured in the warehouse (the sprint_goal field is empty for PI 5 to PI 8). Goals are written as markdown checkbox lists by each team. No trend comparison is possible this cycle, but the spread across teams is informative on its own.

Goal Hit Rate (PI 9 totals)

Goals achieved as % of goals set across all 6 sprints

Fusion

100% · 18/18

Web

88% · 7/8

Data

86% · 6/7

Cloud

83% · 15/18

Mobile

48% · 12/25

Goal-Setting Volume

Average goals set per sprint · counts the ambition of each team's planning

Higher bars = teams that set more goals per sprint. Combined with hit rate, this surfaces whether teams over-promise (Mobile) or set narrow, achievable goals (Web, Data).

Per-Sprint Goal Hit Rate

Goals achieved per sprint · cell shows percentage and done/total · Green ≥ 80% · Yellow 50–79% · Red below 50%

⚠ Mobile S1 and S2 combined hit 1 of 9 goals. Sprint goals like "Make 50% progress on tech debt" and "Internal release using TestFlight and Firebase of BYOD" repeated across both sprints unmet. Worth investigating whether these were external dependencies, mis-scoped goals, or capacity issues.

✦ Standout

Fusion hit every goal it set in PI 9

18 goals set across 6 sprints, 18 achieved. Goals are concrete and deliverable-focused ("CTRT data is uploaded to the cloud", "Coding complete for FSN-39"). Fusion's completion ratio is only 54% on points but the goals they set were always met. That is a healthy split between commitment (capacity-shaped) and goals (confidence-shaped).

✕ Risk

Mobile sets the most goals and hits the fewest

Mobile sets ~4.2 goals per sprint (highest in the org) and achieves 48% of them (lowest). Sprints 1 and 2 combined hit 1 of 9 goals. Several goals repeat verbatim across sprints when missed (Transperfect integration, BYOD push notifications, tech debt). This pattern of recurring un-hit goals is a stronger signal than the completion ratio that scope discipline needs work.

⚠ Tension

Web's high goal hit rate sits next to a 29-point completion drop

Web hit 7 of 8 sprint goals (88%) but missed the broader story-point commitment by 40 points. This suggests goals were narrow and tactical (e.g. "Release carelab 1.8.2") while the bulk of committed Jira work fell through. Goals and completion are measuring different things here, and Web's PI 9 retro should look at both gaps independently.

→ Pattern

Hit rate is inversely correlated with goal volume

Teams that set 1–3 goals per sprint (Web, Data, Fusion) hit 86–100% of them. Teams that set 4+ goals per sprint (Mobile) hit under 50%. This is the same scope-discipline signal that shows up in creep ratios. The takeaway is not "set fewer goals" but "set the goals you have high confidence in completing, and treat the rest as stretch."

Agile Execution

Commitment, Delivery and Scope Control

▶ Commitment vs Capacity (PI 9) · The lens that explains "no team hit 80%"

How much each team committed relative to their own measured sprint capacity. Black bar = 100% of capacity. The story-point completion target of 80% is calibrated against commitment, not capacity.

Team

% of Capacity

Cloud

100%

145% committed

Web

110% committed

Mobile

165% committed

Data

192% committed

Fusion

198% committed

Completion ratio recomputed against capacity

Team	Capacity	Commitment	Done	Done / Commit	Done / Capacity	Reading
Cloud	170.9	247.4	133.8	54%	78%	Just below capacity target. Real delivery healthy.
Data	105.2	201.5	101.75	50%	97%	Effectively at capacity. Commitment is inflated.
Fusion	101.1	200	108	54%	107%	Delivered above capacity. Strong performance.
Mobile	156.0	257.75	170.6	66%	109%	Delivered above capacity. Strong recovery.
Web	152.1	167	100	60%	66%	Below capacity. The only team underdelivering on both bases.

The 80% completion target is currently measured as commit_done / commitment. When recomputed as commit_done / capacity, three of five teams exceeded 100% in PI 9. This is the most important finding for the PMO conversation: the "missed target" narrative is driven by commitment inflation, not by under-delivery. Only Web is meaningfully behind on both measures.

Bugs Completed Per PI

Count of bug-type issues completed per PI

Total Commitment Volume (story points)

Sum of committed points per PI per team

Full Agile Data Table (PI 5 to PI 9)

All teams and PIs · Ratios flagged against targets · PI 9 rows highlighted

Team	PI	Commitment	Done	Completion	Creep	Creep %	Bugs

DORA Metrics

Deployment Frequency (Cloud and Web)

The deployment data model was refreshed between PI 8 and PI 9 to classify environments by tier (production / staging / other) instead of by raw environment name. PI 5 to PI 7 production and staging counts are blank in the current model because the historical environment-to-tier mapping was not back-filled. PI 8 and PI 9 are the only directly comparable points. New repositories added to teams since the previous data pull did not unlock deployment tracking for Data, Fusion, or Mobile, and have not yet produced deployments to any production or staging environment.

Cloud Deployments (PI 8 vs PI 9)

Production and staging tier totals

0.5/day target (production)

Web Deployments (PI 8 vs PI 9)

Production and staging tier totals

0.5/day target (production)

Production Deployment Frequency (deploys per day)

Cloud edges up marginally · Web continues to decline · both remain well below 0.5/day target

Team	Tier	PI 8 Count	PI 8 Freq	PI 9 Count	PI 9 Freq	Target	Status
Cloud	staging	8	0.08/d	7	0.08/d	—	Flat
Cloud	production	4	0.04/d	5	0.06/d	≥ 0.5/d	Improving · still well below target
Web	staging	49	0.51/d	29	0.35/d	—	Declining
Web	production	5	0.05/d	3	0.04/d	≥ 0.5/d	Critical · still declining

⚠ Cloud's production deploy frequency is the only metric trending in the right direction in this section, and only marginally (+1 deploy PI 8 to PI 9). Web is regressing on both deployment activity and sprint delivery simultaneously. Data, Fusion, and Mobile still have no deployment tracking configured even after the recent repository additions.

Developer Activity

Commit Velocity (PI 8 vs PI 9)

Activity data prior to PI 8 is no longer available in the current data model (team_activity_daily coverage starts 2025-10-30). The PI 6 to 8 historical figures from the PI 5-8 doc cannot be reproduced from the warehouse today; PI 8 and PI 9 are the only directly comparable PIs for activity metrics this cycle. Note: team activity is computed from contributor attribution (commits by anyone whose current team is X) rather than project attribution, so the recent additions of repositories to dim_project do not change these totals.

Total Commits by Team (PI 8 vs PI 9)

Absolute commit volume per PI

Active Commit Days (PI 8 vs PI 9)

Days with at least one commit anywhere on the team

Activity Data Table (PI 8 to PI 9)

Every team grew commit activity in PI 9 · throughput on Jira commitments did not match

Team	Contributors	PI 8 Commits	PI 8 Active Days	PI 9 Commits	PI 9 Active Days	Commit Δ
Cloud	7	3,872	97	4,993	81	▲ 29%
Data	5	905	63	2,037	60	▲ 125%
Fusion	4	515	54	542	54	▲ 5%
Mobile	9	8,790	77	9,893	71	▲ 13%
Web	6	841	64	1,309	60	▲ 56%

⚠ Every team grew commit activity in PI 9, yet only Mobile materially improved Jira throughput. The MR view below is a better proxy for actual delivered units of work.

Merge Request Throughput (PI 8 vs PI 9)

MRs opened, merged, and closed-without-merge per team · MRs are a more honest unit-of-work signal than raw commit counts

Team	PI 8 Opened	PI 8 Merged	PI 9 Opened	PI 9 Merged	Merged Δ	PI 9 Closed-no-merge	Approvals / Merge
Cloud	189	331	420	466	▲ 41%	117 (20%)	1.22
Data	69	53	294	277	▲ 423%	21 (7%)	1.29
Fusion	59	51	110	104	▲ 104%	16 (13%)	0.78
Mobile	407	400	727	646	▲ 62%	85 (12%)	3.13
Web	109	105	149	137	▲ 30%	13 (9%)	0.56

Three signals to read out of this table. 1. MR throughput grew for every team, materially so for Data and Fusion. This is the activity-vs-throughput gap reconciled: real delivery did increase in PI 9; the gap to Jira completion is the over-commitment problem from the capacity panel above. 2. Closed-without-merge rate jumped for Cloud (13% → 20%) and Mobile (5% → 12%) — worth understanding whether MRs are being abandoned, superseded, or rejected. 3. Approvals per merge is a review-depth proxy. Mobile averages 3.13 (heavy review); Web averages 0.56 (less than one approver per merge on average — possibly a process gap).

Team Profiles

Per-Team Assessment (PI 9)

☁ Cloud

Completion (vs Commit) 54%

Delivery (vs Capacity) 78%

Sprint Goals 83% · 15/18 ✓

Creep 25.7% ⚠

Bugs / MRs Merged 21 / 466

Prod deploys 5 (0.06/d)

Sprint goals hit rate is solid (83%) and delivery against capacity is just below target (78%). Commitment is inflated (145% of capacity). Creep above ceiling. Bug count doubled. MR closed-without-merge rate jumped to 20%.

Topics for Nick

Why did closed-without-merge MRs nearly triple (50 → 117)?
Are bugs (21, up from 10) absorbing planned capacity?
What unblocks production deploy frequency past 0.1/day?

◈ Data

Completion (vs Commit) 50%

Delivery (vs Capacity) 97%

Sprint Goals 86% · 6/7 ✓

Creep 9.1% ✓

Bugs / MRs Merged 10 / 277

Commit Growth +125%

Best creep result in the dataset. Delivered effectively at capacity (97%). MRs merged quadrupled (53 → 277). Sprint goal hit rate strong. Commitment heavily inflated (192% of capacity) — the "low" completion ratio is a calibration artifact, not a delivery issue.

Topics for Vlad

What drove the creep collapse (33% → 9%)? Codify it.
Recalibrate commitment to capacity for PI 10?
Goals tend to be sparse (1.4/sprint) — set more concrete goals?

⊕ Fusion

Completion (vs Commit) 54%

Delivery (vs Capacity) 107%

Sprint Goals 100% · 18/18 ✓✓

Creep 11.5% ✓

Bugs / MRs Merged 5 / 104

Review depth 0.78 ⚠

Hit every sprint goal. Delivered above capacity (107%). Creep dropped 27pp. Bugs cut by two-thirds. The strongest all-round PI of any team. Two watch items: commitment is heavily inflated (198% of capacity) and approvals-per-merge is below 1.

Topics for John

Share the planning practices that drove 100% goal hit rate.
Commitment is 198% of capacity — is this aspirational or estimation drift?
Are MRs getting enough review (0.78 approvals/merge)?

⬡ Mobile

Completion (vs Commit) 66%

Delivery (vs Capacity) 109%

Sprint Goals 48% · 12/25 ✕

Creep 32.0% ✕

Bugs / MRs Merged 90 ⚠ / 646

Best PI ever ▲ +16pp

Big completion gain and delivery above capacity (109%). Bugs down 36. But the goal-setting picture is the opposite story: 48% hit rate, four goals repeating unmet across sprints. Creep still over ceiling. Mixed signals worth understanding.

Topics for Kartik

What changed between PI 8 and PI 9 — and is it sustainable?
Why do goals like Transperfect / BYOD push notifications keep recurring unmet?
90 bugs is still highest in org — quality investment plan for PI 10?

⬡ Web

Completion (vs Commit) 60%

Delivery (vs Capacity) 66%

Sprint Goals 88% · 7/8 ✓

Creep 26.9% ✕

Bugs / MRs Merged 4 ✓ / 137

Prod deploys 3 (0.04/d)

The only team underdelivering against capacity (66%). Hit narrow sprint goals (88%) but the bulk of committed Jira work missed. Creep nearly tripled. Deploys dropped at both staging and production. Bug count and review depth both low — quality not the issue.

Topics for Jeff

The 29pp drop is the largest in the dataset — what specifically happened?
Goals hit (88%) vs commitment hit (60%) — what was in the gap?
Review depth at 0.56 approvals/merge — is the MR process being skipped?

✕ Critical Signal

No team hit the 80% completion target in PI 9

In PI 5 through PI 8, Web cleared 80% three times. In PI 9, zero teams cleared it. Either the target is wrong, commitments are systematically inflated, or capacity has dropped across the org. This is the first PI in the trend window with a zero pass rate on the primary agile target.

✦ Standout

Mobile's reversal is the standout PI 9 outcome

Up 16 points on completion, down 17 on creep, down 36 on bugs. After being flagged as the most troubled team in PI 8, Mobile has produced its best PI on every measure that matters. The retrospective should focus on what specifically changed — process, leadership, scope discipline, or external pressure — and whether the gains are sustainable.

⚠ Pattern

Activity grew everywhere, throughput did not

Every team posted higher commit counts in PI 9 than PI 8 (Data +125%, Web +56%, Cloud +29%, Mobile +13%, Fusion +5%). Yet only Mobile materially moved completion. The most likely explanations are bug work absorbing capacity (Cloud bug count doubled), uncommitted-but-real engineering effort, or sprint commitments that don't reflect actual sprint loading.

→ Signal

Creep is no longer a systemic problem

In PI 8, four of five teams breached the 20% creep ceiling. In PI 9, only Cloud (25.7%), Mobile (32%), and Web (26.9%) did. Data and Fusion fixed it. The org-wide pattern noted in the PI 5-8 doc has materially improved — three teams still need work, but it is no longer "almost everyone".