PI 10 mid-PI · Cross-team read-out

Team status dashboard

The planning swing

Cloud, Data, and Web swung from over-committing to under-committing in a single PI. Cloud went from 127% to 83%, Data from 186% to 73%, Web from 95% to 61%. Fusion landed at 104% — the most balanced planning of any team in the trend window. Mobile is the only team continuing to commit above capacity (149%, similar to PI 9's 145%).

Trends across teams

Final releases this PI

Goal progress

Topics for the conversation

1. Was the PI 10 planning swing intentional, and how do we feel about the new calibration? Four teams cut their commitment vs capacity ratio dramatically after PI 9 missed targets across the board. The result is easier completion targets but creep ratios that have exploded on Cloud (51%), Data (77%), and Web (36%). The headline question for PMO and leadership: was this a deliberate calibration correction, or an over-correction? If deliberate, do we want to lock it in for PI 11? If not, what would balanced planning look like (Fusion's 104% is the closest example we have)? Why this matters · The 80% completion target loses meaning if commitment is just dialled down to make it easier to hit. Creep ratio at 50-80% is also signalling that demand is not actually smaller.
2. Mobile committed above capacity again, but the bug pattern is significantly better. Mobile is the only team still committing above capacity (149%, similar to PI 9's 145%). Their completion (55%) and creep (26%) projections look similar to PI 9. But their bug projection is 52 — down from 90 in PI 9 and 116 in PI 8. That's a real quality improvement. Question for the room: is Mobile's commitment pattern healthy because the team can absorb it, or should they follow the other teams' calibration? Why this matters · Mobile's commitment behaviour and outcomes have stayed remarkably consistent. The team may have found a stable operating point, even if it doesn't look like the other teams.
3. MR throughput is down on every team — not just Web. Projected merged MR counts vs PI 9 actuals: Cloud 93 (vs 474, -80%), Data 90 (vs 279, -68%), Fusion 56 (vs 104, -46%), Mobile 101 (vs 648, -84%), Web 11 (vs 137, -92%). Pace per active day is down on every team by a similar margin. This is a system-wide signal that the work flowing through GitLab is materially lower than PI 9, even on teams whose Jira completion projections look fine. Two reasonable hypotheses: (a) PI 9 had unusually high cleanup or migration activity inflating its baseline, or (b) teams are doing fewer, larger merges this PI. Question for the room: is this pattern visible in standups, or news to people? Why this matters · Jira metrics can be tuned by changing what gets put on the board. MR counts can't be tuned without changing how work actually flows. A 50-90% drop across the board is the kind of finding that should be either explained or investigated, not absorbed.
4. Web has a productivity gap we can't fully explain from the data. Web's completion projects at 58%, delivery vs capacity at 48% (both red), MR throughput is at 7 merged in 44 days (vs 137 across all of PI 9 with the same team size). Production deploys flat. The team has shipped two prolaio-ui finals and S3 caught up on sprint goals — so they are delivering, just at a fraction of the previous rate. The question for leadership: do we know what's happening on Web, and what would the team say if asked? Why this matters · Two consecutive PIs with this pattern (PI 9 regression and PI 10 mid-PI under-delivery) is no longer noise. Worth a direct conversation with Jeff.
5. Cloud's release cadence has stalled in PI 10 despite tagging activity. PI 9 was a clean Pass: 5 platform releases deployed to production across 5 active sprints, hitting the 1-per-sprint goal exactly. PI 10 is at 1 deployed (3.10.15.0 on 7 May) after 3 active sprints. 3.10.16.0 was tagged 3 Jun but has not yet shipped to production. The GitLab tag log shows more activity than the deploy log — for instance, 3.10.14.0 was deployed in PI 9 (7 Apr) but only tagged on 7 May, so historical reports built from tags alone under-counted PI 9 and over-counted PI 10. Question: what is delaying 3.10.16.0 and the broader PI 10 release cadence, and what would unblock it? Why this matters · The release cadence goal is measured against production deployments (per Nick's OKR), and Cloud is meaningfully behind. The tag-vs-deploy delta also creates a data hygiene issue that affects reporting consistency.
6. Data and Web have a sprint-goal tracking hygiene gap. Both teams have written sprint goals for S1-S3 but Data has 0 of 3 boxes ticked and Web has 0 of 5 for S1-S2 (S3 caught up). Same pattern as PI 9. The likely explanation is that goals are written at sprint start but never updated at sprint close — not that work isn't happening. The question for PMO: do we want goals enforced as a tracking ritual, or accept that for some teams the boxes are aspirational rather than reflective? Why this matters · If we are using sprint-goal hit rate as a KR for the shared "≥ 80% goal achievement" target, those KRs are not actionable for teams who aren't keeping the boxes current.
7. Fusion is the closest thing we have to a "balanced PI" example. Commitment at 104% of capacity. 100% sprint goal hit rate. Creep at 13% (under ceiling). Bugs at 8. 4 final releases — already double PI 9's full total. Question for the room: what is Fusion doing that the other teams aren't, and how do we make that learnable rather than tacit? Why this matters · If we have one team consistently operating well, we should be intentional about identifying what's different about their process and PO collaboration.

Method and caveats

Run-rate extrapolation. Sprint-based metrics (completion, creep, bugs, velocity) are scaled by 5 / active_sprints_elapsed, where active sprints exclude the IP sprint (sprint 6). Today this is approximately 1.61×. Commitment and capacity are taken from the full PI plan since both are already loaded.

What this report cannot tell you. Extrapolation assumes the second half of the PI runs at the same rate as the first. In practice teams accelerate or decelerate based on dependencies, release crunches, or holidays. Treat projected numbers as directional. The Mobile and Fusion projections are most likely to be accurate (similar PI 9 patterns). Cloud, Data and Web projections are more uncertain because the planning shape changed.

Cloud release filter. Cloud "releases" count `cloud-platform-environment` GitLab releases only — the project that ships to production. Component-level CI tags from rest-api, beam-processors, and flink-maps-stream-inspector are excluded because they fire on every commit and would inflate the count by ~10×.