Engineering Performance · PI 11 Close-Out
PI 11 · Cross-Team Report
All five teams, 22 July – 14 October 2026, six sprints. Benchmarked against
PI 10 and PI 9. Rate metrics (demand, completion, creep, velocity vs capacity) exclude S6, the IP
sprint; totals and counts include it.
The short version
PI 11 is the first PI on record to clear the 80% sprint-goal target — 61 of 73 goals,
83.6%, up from 76% in each of the two PIs before it. It did so while doing measurably
less: capacity fell for the third PI running (767 → 745 → 718 points), velocity followed
(746 → 708 → 680), and output per engineer fell for the second consecutive PI —
7% in PI 10, a further 4% in PI 11.
The org is making smaller promises and keeping them. Whether that is discipline or contraction is
the question this report cannot answer and the meeting should.
Where PI 11 landed
Totals across all six sprints; rates across S1–S5.
Sprint goals hit
83.6%
61 of 73 · PI 10 76.2% · target 80%
Velocity
680.4
points · PI 10 708 · PI 9 746.4
Demand ÷ capacity
192%
S1–S5 · PI 10 196% · PI 9 205%
Output per engineer
96
index vs PI 10 · 100 = unchanged
MRs merged
1,087
PI 10 1,082 · index 100
Bugs resolved
113
PI 10 123 · PI 9 130
Release tags
113
49 final · 64 pre-release
Production deploys
6
PI 10 6 · PI 9 8 · Cloud + Web only
Completion ratio diagnostic
44.7%
PI 10 46.4% · PI 9 47.1%
Creep ratio diagnostic
42.7%
PI 10 52.9% · PI 9 30.6%
Commitment ÷ capacity diagnostic
135%
PI 10 128% · PI 9 157%
Capacity, commitment and velocity by sprint
Org totals, PI 11 S1–S6. S6 is the IP sprint.
Commitment tracks far above capacity in every sprint except S5, where it
dropped to 132 points against 118 of capacity — the one sprint of the PI where the plan was
roughly the size of the team. S5 also produced the highest velocity-to-capacity ratio of
the PI.
MRs merged by team
PI 10 vs PI 11, all six sprints.
Commits by team
PI 10 vs PI 11, all six sprints.
Activity split sharply by team. Cloud and Mobile both grew — Cloud +72 MRs and
+767 commits, Mobile +86 MRs and +1,156 commits. Data, Fusion and Web all contracted,
Data most of all: 131 MRs to 66 and 1,994 commits to 683, after losing two engineers at the
S1/S2 boundary.
Sprint goals
Every goal each team set in PI 11, with the team's own wording. This is the
metric that carries the commitment — the selected backlog is a forecast.
Org hit rate
83.6%
61 of 73 goals · target ≥80%
Teams at 100%
2
Fusion 19/19 · Web 7/7
Teams below target
1
Mobile 12/21 · 57%
Mobile's share of misses
8 / 12
of all goals missed org-wide
Sprint goal hit rate
Org, by sprint across PI 11, against the 80% target.
Four of six sprints cleared 80%. The two that did not are the bookends:
S1 (78.6%), where Mobile's release train slipped out of the gate, and S6 (63.6%), the IP sprint,
where four goals — two of them Mobile's, again — went unticked.
Goals by team
Cloud 17/19 · 89%
- ✓Deploy release 3.12.x S1
- ✕ZBeats PDP (first approval) S1
- ✓Deliver the Kardigan EDC backfills S1
- ✓Improve the lag situation from where it is now S1
- ✓ZBeats PDP - to have the first approval S2
- ✓To complete the ticket about an investigation of Beam Router degradation. S2
- ✓Pentest findings: everyone contributes to Pentest tickets (at least one). S2
- ✓All pen test fixes (including needed SDS) deployed and running in pre-prod S3
- ✓Cloud is able to run DS validation scripts S3
- ✓ZBeats implementation: SDK is merged S3
- ✓Finalize a release process schedule S4
- ✓Consistent and reliable passes in qe-cloud eg 4/5 (80%) S4
- ✓Have final tag for 3.14.0 S4
- ✓Setup a GeoGuesser Session S5
- ✓Release 3.16.0 stabilization branch S5
- ✓To complete Terraform ticket VA-8 S5
- ✓Release 3.14.0 deployed on Production S6
- ✕To have runbooks ready for QE to start testing ZBeats S6
- ✓To have 3.16.0 final tag S6
Data 6/7 · 86%
- ✓DES Release 1.1.0 - to have RC S1
- ✓To have a temporary solution for a special access to production S1
- ✓Get DES 1.1.0 technical work done and fully approved S2
- ✓Start work on CDS spike about migration S2
- ✓Release 1.2.0 on pre-prod S3
- ✓Completed assets for Web: scheduled task and scheduled tasks completion S3
- ✕To deploy 1.2.0 on pre-production S6
Fusion 19/19 · 100%
- ✓PSR v2 project is made in PSR repo S1
- ✓X-Cures JIRA project is created and set S1
- ✓To make CTRT FE infrastructure ready for production S1
- ✓Development completed for PSR rate limit issue S2
- ✓Development completed for XCures external identifier check S2
- ✓To complete FE CTRT OCORO tickets. S2
- ✓XCures requery ticket should be completed (dev env.). S3
- ✓Common PSR work - 5 SP should be completed. S3
- ✓CHDI-6 XCures Deployment Setup Completed S4
- ✓CHDI-3 XCures Verification of Unit Tests and Ketryx Mappings (WIP) S4
- ✓PSR-EVO2 Feature Flag Turned On - Dev Complete S4
- ✓PSR Activity Flag Implementation (FE + BE) - Dev Complete S4
- ✓PSR v2 Complete Vital Sign Chart Pages - Dev Complete S4
- ✓xCures job deployment to be completed S5
- ✓n8n xCures work to be completed S5
- ✓OTTO-35 FedEx to be completed S5
- ✓To complete FE development work on Generalized PSR epic. S5
- ✓OTTO-36 should be completed S6
- ✓CLOUD-7974 to be completed S6
Mobile 12/21 · 57%
- ✕6.4.0.0 - release - Not achieved, features got delayed S1
- ✓Prevent Language selection S1
- ✕BYOD Device Alert synchronization - Not achieved, waiting on MR approval S1
- ✓Release 6.4.0.0 (Carry over) S2
- ✓Device Alerts Sync (Carry over) S2
- ✕6.4.2.0 RC S2
- ✓6.4.2.0 release S3
- ✓6.4.2.0 Release Candidate S3
- ✓ePRO Branching logic S3
- ✕TLA-202 Safety Careplan switching S3
- ✓RC 6.4.4.0 S4
- ✓Finalize translation orders S4
- ✕Kick off BYOD internal beta testing S4
- ✓Release 6.4.4.0 S5
- ✕Kick-off BYOD beta testing (UXR group) S5
- ✓Safety Care-Plans (dev) S5
- ✕iHealth weight scale (dev) S5
- ✕Kick-off BYOD beta testing (UXR group) S6
- ✕6.4.6.0 Release S6
- ✓kardepro training session S6
- ✓kardepro release S6
Web 7/7 · 100%
- ✓Dev complete (at least MR review) for REST API for listing Orgs for a User. S1
- ✓Define requirements for v1 Clinical Reporting Tool. S1
- ✓Resolve issues related to pentest findings S2
- ✓Wrap-up participant tab and roll out on pre-production server S3
- ✓initialize clinical trial reporting tool(code repository is created and initial website in it) S4
- ✓finalize query for adherence S5
- ✓ATA careplan migration script S6
One pattern dominates the misses
Mobile missed the same two things repeatedly. "Kick off BYOD beta testing"
was set and missed in S4, S5 and S6. The 6.4.x release train missed in S1 (6.4.0.0),
S2 (6.4.2.0 RC) and S6 (6.4.6.0). Eight of the org's twelve missed goals are Mobile's, and
six of those eight are one of these two items restated.
Goal checkboxes are edited after a sprint closes. The PI 11 S3 weekly report published on
10 September recorded 8 of 12 for that sprint; the same query now returns 11 of 12 because teams
ticked boxes later. Figures in this report are as of 16 October 2026.
Releases
Every version tagged inside a team's own sprint windows during PI 11.
A tag is not a release — the production deploy can lag the tag by days or weeks.
| Team | Tags | Final | Pre-release | Prod deploys |
|---|
| Cloud
beam-processors · cloud-platform-environment · flink-maps-stream-inspector · rest-api |
33 | 24 | 9 |
4 |
| Data
data-ecosystem · data-ecosystem-core · data-ecosystem-infrastructure · data-platform-ci |
24 | 5 | 19 |
— |
| Fusion
pmr-hcm · xcures |
13 | 9 | 4 |
— |
| Mobile
clinical-mobile-app · health-devices-ble-library · prolaio-monitor |
40 | 9 | 31 |
— |
| Web
prolaio-ui · prolaio-web · prolaio-workbench |
3 | 2 | 1 |
2 |
| All teams | 113 |
49 | 64 |
6 |
113 tags produced six production deployments. The ratio is the story. Mobile
tagged 40 times — 31 of them alpha, beta or release-candidate builds of the same 6.4.x train — and
Data tagged 24 times with only 5 final versions, all release candidates of 1.1.0 and 1.2.0 that
never left pre-production. Data's PI closed on the one goal it set in S6: "To deploy 1.2.0 on
pre-production", unticked.
Cloud is the counter-example and corroborates its goals exactly: 3.13.0 (S1), 3.14.0
final tag (S4), 3.14.0 deployed to production and 3.16.0 final tag (S6) — each one matches
a ticked goal, and Cloud's four production deployments are the most of any team. Fusion shipped
xCures 1.0.0 in S5 and pmr-hcm 4.5.0 and 4.6.0, every one against a ticked goal.
Bugs
Bug and Anomaly issues completed during PI 11, by the team that owns the
board. Headline counts come from the sprint boards; the High-or-above column is derived from
issues by resolution date and uses a slightly wider population.
Share of the org's 113 resolved bugs
Proportion of the PI 11 bug load, by team.
Bugs resolved by PI
Org total, PI 9 → PI 11.
| Team | PI 11 | PI 10 | Δ | Share | High+ |
|---|
| Cloud |
19 | 23 | ▼ 4 |
17% | 12 |
| Data |
15 | 28 | ▼ 13 |
13% | 1 |
| Fusion |
6 | 13 | ▼ 7 |
5% | 1 |
| Mobile |
65 | 53 | ▲ 12 |
58% | 9 |
| Web |
8 | 6 | ▲ 2 |
7% | 6 |
| All teams | 113 | 123 |
▼ 10 | 100% | 29 |
Org bug load fell for the second PI running, 130 → 123 → 113. Mobile is the only team
that went the other way, 53 → 65, and now carries 58% of the org's resolved bugs on 31%
of its headcount. Mobile also runs the heaviest quality investment in the org — six engineers to
three QE — so the count reflects detection capacity as much as defect injection. Data's drop from
28 to 15 coincides with its headcount halving, not with a quality improvement.
Demand vs capacity
Total scope surfaced — commitment plus creep — against capacity, S1–S5.
The headline planning metric: was the plan physically possible?
Demand ÷ capacity by PI
Org, S1–S5. The most stable number in the dataset.
Four PIs of demand: 211%, 206%, 200%, 196% for PI 8–11 on
the all-sprint basis, and 205% → 196% → 192% on the S1–S5 basis shown here. Whatever changes about
planning, roughly twice as much work surfaces as the teams have capacity for, and roughly 95% of
capacity gets completed. That is a prioritisation and staffing question, not a team
discipline question.
| Team | Demand ÷ cap | PI 10 | Commit ÷ cap | Velocity ÷ cap |
Completion | Creep |
|---|
| Cloud |
227% | 167% |
150% | 111% |
43.5% | 50.7% |
| Data |
195% | 223% |
109% | 89% |
35.5% | 79.8% |
| Fusion |
197% | 198% |
153% | 101% |
51.7% | 29.0% |
| Mobile |
227% | 247% |
185% | 91% |
36.7% | 22.4% |
| Web |
116% | 154% |
72% | 70% |
67.5% | 60.8% |
| All teams | 192% |
196% | 135% |
92% | 44.7% |
42.7% |
How to read completion and creep
Both are shown as diagnostics, not targets. They share a denominator —
commitment — that the team sets at planning, and the 80% / 20% targets pull it in opposite
directions. Across 93 sprints, no sprint has ever hit both. The volume of
unplanned work arriving is statistically unrelated to the size of the plan (r = −0.11, p = 0.30),
so creep ratio moving is denominator arithmetic rather than less interruption.
The intent behind those targets — better planning, predictable delivery — is right, and the
underlying problem is real. Sprint goal achievement, demand vs capacity and forecast error carry
that intent without the flaw.
Web is the one team planning inside its own capacity at 116% demand, and it hit
7 of 7 goals. Cloud and Mobile both sat at 227% — more than twice what they could physically do —
and between them account for every goal missed outside the IP sprint bar one.
Team scorecard
PI 11 totals across all six sprints; demand across S1–S5.
Story points are not comparable across teams — capacity per engineer ranges from 2.1 to 3.9 points,
which is estimation scale, not availability. Read each row against its own history, not its neighbours.
| Points | Promises |
Activity | Ship |
|---|
| Team | Capacity | Commitment | Velocity |
Demand | Goals |
MRs | Commits | Bugs | Tags |
|---|
| Cloud
6 delivery avg |
178.8 | 269 | 199.6 |
227% | 17/19 |
458 | 4,983 | 19 |
33 |
| Data
4.3 delivery avg |
99.8 | 113 | 83.2 |
195% | 6/7 |
66 | 683 | 15 |
24 |
| Fusion
4.7 delivery avg |
104.7 | 165 | 120 |
197% | 19/19 |
74 | 726 | 6 |
13 |
| Mobile
9.7 delivery avg |
164.9 | 319.6 | 147.6 |
227% | 12/21 |
421 | 7,142 | 65 |
40 |
| Web
6 delivery avg |
169.8 | 117.5 | 130 |
116% | 7/7 |
68 | 814 | 8 |
3 |
| All teams | 718 | 984.1 |
680.4 | 192% |
61/73 | 1,087 |
14,348 | 113 | 108 |
Output per engineer
Each team against its own PI 10 per-engineer average, across all
six sprints. 100 means unchanged. Delivery roster = engineers, QE and interns; PMO and Product Owners
excluded. This is a trend per team, never a league table.
Per-engineer index vs own PI 10 baseline
100 = unchanged. Points, MRs merged and commits.
| | Points |
MRs merged | Commits |
|---|
| Team | Roster | per eng | index |
per eng | index | per eng | index |
|---|
| Cloud |
6 |
33.3 | 121 |
76.3 | 119 |
830 | 118 |
| Data |
4.3 |
19.4 | 94 |
15.3 | 67 |
159 | 45 |
| Fusion |
4.7 |
25.5 | 79 |
15.7 | 48 |
154 | 67 |
| Mobile |
9.7 |
15.2 | 76 |
43.4 | 117 |
736 | 111 |
| Web |
6 |
21.7 | 112 |
11.3 | 69 |
136 | 53 |
| All teams | 30.7 |
22.2 | 96 |
35.4 | 100 |
467 | 98 |
Points per engineer fell 4% org-wide, after a 7% fall in PI 10 (index 93 then 96).
Compounded, the org completes about 89% of the points per head it did in PI 9 on an almost identical
roster. Activity stopped falling: MRs per engineer came back to 100 after PI 10's 84, and commits to
98 after 76.
The org figure hides a wide spread. Cloud is up on all three measures
(121 / 119 / 118) and Web's points per engineer rose 12% on sharply lower activity.
Mobile's points per engineer have now fallen three PIs running — 25.6 → 20.1 → 15.2,
down 41% from PI 9 — while its MRs per engineer rose 17% and its bug count grew. Mobile is doing more
work that is not landing as board points. Fusion dropped on all three (79 / 48 / 67)
in the PI it swapped one engineer for two; it still hit 19 of 19 goals, which says its goals got
smaller along with its output.
Per-team read
What each team's PI 11 numbers say, against its own history.
Cloud Grew on every activity measure and shipped the most
19 goals set, 17 hit (89%) — and the release record corroborates them exactly:
3.13.0 in S1, the 3.14.0 final tag in S4, 3.14.0 to production and the 3.16.0 final tag in S6.
Four production deployments, the most of any team. Per-engineer output rose on all three measures (points 121, MRs 119, commits 118) on an
unchanged six-person roster. It tagged 33 releases, 24 of them final — the highest final share of
any team. The two misses were both the same ZBeats workstream — the PDP first approval in S1
(closed in S2) and QE runbooks in S6.
Against that:
demand ran at 227% of capacity, the joint-highest in the org,
and completion sat at 43.5%. S5 is the clearest illustration — a 19-point commitment against 36.6 of
capacity, then 59 points of creep arrived and the team completed 56. The plan bore almost no relation
to the sprint that happened, yet the sprint itself went well.
Goals 17/19Prod deploys 4Points index 121MR index 119Demand 227%
Data Half the team, two-thirds of the goals, and nothing reached pre-production
Data lost Jesse Zuckerman and Vladimir Pasquier on 5 August, at the S1/S2 boundary — together 77% of
the team's commits — and the replacement hire was a Product Owner. The delivery roster went from 6 to
4.
Commits fell 1,994 → 683 (index 45) and MRs 131 → 66.
What the team did keep was quality of promise:
6 of 7 goals hit, and points
per engineer held almost steady (index 94) because the denominator shrank nearly as fast as the output.
But
the team logged no sprint goals at all in S4 or S5, so the 7-goal denominator
covers four sprints, not six — read the 86% with that in mind.
The one goal missed is the one that mattered:
"To deploy 1.2.0 on pre-production" in
S6. Data tagged 24 versions in PI 11; five were final and none of the 1.2.0 line left pre-production.
Goals 6/7Roster 6 → 4Commits 683Commit index 45Tags 24
Fusion Hit every goal it set, on steadily less output
19 of 19 goals, the second PI running at 100%. xCures 1.0.0 shipped in S5, pmr-hcm
4.5.0 in S4 and 4.6.0 in S6, each against a ticked goal. Demand at 197% was mid-pack and completion
at 51.7% was the second-best in the org.
The trajectory underneath is the thing to look at.
Per-engineer output fell on all
three measures — points 79, MRs 48, commits 67 — and this follows a PI 10 where MRs and
commits per head were up 62% and 70%. Velocity per engineer has gone 29.8 → 32.4 → 25.5 across the
three PIs.
The roster changed mid-PI: Avinash Gupta out on 10 September, Grant Smith and Tyler Lofgren in the
same day, taking the team from 4 to 5.
A team at 100% goal achievement with falling throughput is a team whose goals are tracking its
output downward. That is worth a conversation about goal ambition, not about effort.
Goals 19/19Points index 79MR index 48Roster 4 → 5Demand 197%
Mobile The most activity, the most bugs, and two-thirds of the org's missed goals
12 of 21 goals (57%) — the only team below target, and the source of 8 of the org's 12
misses. Six of those eight are two items restated: "kick off BYOD beta testing" was set and
missed in S4, S5 and S6; the 6.4.x release train missed in S1, S2 and S6.
This is not an activity problem.
Mobile merged 421 MRs and made 7,142 commits, both
the most in the org, and both up sharply on PI 10 (MR index 117, commit index 111). It tagged
40 releases. It also resolved
65 bugs, 58% of the org's total and the only team whose
bug count rose.
What is falling is points.
Velocity per engineer has dropped three PIs in a row —
25.6 → 20.1 → 15.2, down 41% since PI 9 — while commitment stayed at 320 points against 165
of capacity. Mobile plans roughly twice what it can do, generates the most code in the company, and
converts less of it to completed board items each PI. The 31 alpha/beta/RC tags against 9 finals
point at the same place: a long verification tail.
Goals 12/21Bugs 65MRs 421Points index 76Demand 227%
Web The only team whose plan fit its capacity — and it hit everything
7 of 7 goals, and demand at 116% of capacity — by a wide margin the most realistic
plan in the org, where everyone else ran between 195% and 227%. Completion at 67.5% was the highest
of any team and creep absorbed the rest. S3 was the standout: 30.5 points completed against 31.8 of
capacity, with 24.5 of a 30.5-point commitment done.
Set against that,
code activity contracted sharply: MRs 99 → 68 (index 69)
and commits 1,526 → 814 (index 53) on an unchanged six-person roster, with three release tags all PI.
Points per engineer went the other way, 19.4 → 21.7 (index 112) — the team completed more board work
from less code movement.
Web also has the org's worst production lead time:
a 53-day median on
prolaio-workbench, up from 34 days in PI 10, against a 7-day target. Two production
deployments in a PI with 26 staging deployments is the same promotion bottleneck in another form.
Goals 7/7Demand 116%Completion 67.5%MR index 69Lead time 53d
Delivery flow
DORA measures. Coverage is partial — only Cloud and Web have production and
staging environments mapped. Mobile has app-store testing channels only; Data and Fusion have
dev only.
Production deployments by PI
Cloud and Web, the two teams with production environments mapped.
Median lead time to production
Days from commit to production deploy, against the 7-day target.
Six production deployments across the whole PI — level with PI 10 and down from
8 in PI 9 — against 36 staging deployments. Cloud accounted for four of the six; Web for two. The
bottleneck is promotion, not build or test.
Lead time moved in opposite directions. Cloud improved sharply — a 24–25 day median
against PI 10's 39–40 — but is still three and a half times the 7-day target and nowhere
near PI 9's 6–15 days. Web went the other way: 34 days to 53 on prolaio-workbench,
with a p90 of 57. Neither team is close to target, and no other team can be measured at all.
What the warehouse still cannot tell you
No open-bug backlog — issues carries only completed bugs, so inflow and ageing are
invisible. No cycle time and no WIP. DORA coverage reaches two of five teams. Closing the
cycle-time and open-bug gaps would do more for this report than any new chart.
Method
Source. prolaio-engineering-metrics.metrics in BigQuery, pulled
16 October 2026. PI 11 ran 22 July – 14 October 2026 across six sprints; each team has its own
sprint boundaries, and every window-based figure uses the team's own dates.
IP sprint. S6 is the Innovation & Planning sprint. Rate metrics — demand ÷
capacity, commitment ÷ capacity, velocity ÷ capacity, completion and creep — are computed over
S1–S5 so the comparison is against normal delivery sprints. Totals and counts — velocity, capacity,
bugs, MRs, commits, release tags, deployments and sprint goals — include all six.
sprint_pi_summary pools all six for its ratios too, so its completion and creep figures
differ from the ones here.
Ratios are point-weighted (SUM(x)/SUM(y)), not averages of
per-sprint ratios. Committed Done is work committed at sprint start and completed,
at its end-of-sprint estimate; Velocity is committed done plus creep done.
Sprint goals are parsed from the markdown checkboxes teams write in
sprints.sprint_goal, verbatim. Teams edit these after a sprint closes,
so the same query run weeks apart returns different figures — PI 11 S3 read 8/12 on 10 September and
11/12 today. All goal figures here are as of 16 October 2026.
MRs are attributed to the author's team at the time of the event, from
events joined to dim_contributor; accepted means merged.
Bug headline counts come from the sprint boards; the High-or-above split is derived
from issues by resolution date, mapped to teams by JIRA project prefix, and runs a few
issues wider than the board population.
Delivery roster = engineers, QE and interns. Product Owners and PMO are excluded;
Galina Rozina holds three simultaneous team memberships in the warehouse and is excluded from all of
them. Jonathan Seigal (QE) is counted once, under Data; he picked up a second Cloud membership on
9 October. Three PI 11 joiners have unconfirmed roles — Domenic LaVitola (Mobile,
1 Sep), Grant Smith and Tyler Lofgren (Fusion, 10 Sep) — and are counted as delivery here. If any
is a PO, Mobile's and Fusion's per-engineer indices move up.
Completion ratio and creep ratio are shown as diagnostics with no pass/fail colouring.
See Engineering Metrics — Diagnosis and Proposal for the full analysis.