Product & Engineering Leadership · Weekly · PI 11 Sprint 3
Best completion of the PI · nothing reached production
All five teams for the last closed sprint, 18 August to 2 September 2026, benchmarked against the PI 10 per-sprint average over S1 to S5. The IP sprint is excluded from the baseline so the comparison is against a normal delivery sprint. PI 11 S4 opened on 1 September and is excluded throughout.
The short version
Completion reached 49.9%, the best of the PI, and velocity held at 98% of capacity — but zero production deployments. Cloud held 3.14.0 at rc.2 in preproduction, Data's 1.2.0 stayed at rc.1, Web deployed only to staging, and Mobile tagged 6.4.2.0 on the sprint's closing day while marking the release goal missed. Sprint goals fell to
8 of 12, 66.7% — the weakest of the three sprints — and bugs rose to 26. Demand held at 196% of capacity, the third straight reading around 200%.
Demand vs Capacity
196%
196% in PI 10 · level
Commitment vs Capacity
150%
128% in PI 10 · 129% in S2
Velocity vs Capacity
98%
96% in PI 10 ▲ 2pp
Production Deploys
0
3 in S2 · 1.2 per sprint in PI 10
Completion Ratio diagnostic
49.9%
46.4% in PI 10 ▲ 3.5pp
Creep Ratio diagnostic
30.9%
52.9% in PI 10 ▼ 22.0pp
Sprint Goals Hit
8 / 12
66.7% · target ≥ 80%
Capacity, Commitment, Velocity
PI 11 S3, story points. Fusion is the outlier — velocity at 38% of capacity.
Merge Requests Merged
S3 against the PI 10 per-sprint average. Attribution is by author's team, not repository.
Sprint goals
Every goal as written in JIRA. 8 of 12 hit — 66.7%, below the ≥80% shared target and down from 91.7% in S2. Data missed both of its goals, the first zero-goal sprint by any team this PI.
Cloud 3 of 3
- ✓ All pen test fixes (including needed SDS) deployed and running in pre-prod
- ✓ Cloud is able to run DS validation scripts
- ✓ ZBeats implementation: SDK is merged
Data 0 of 2
- ✕ Release 1.2.0 on pre-prod
- ✕ Completed assets for Web: scheduled task and scheduled tasks completion
Mobile 2 of 4
- ✓ 6.4.2.0 Release Candidate
- ✓ ePRO Branching logic
- ✕ 6.4.2.0 release
- ✕ TLA-202 Safety Careplan switching
Fusion 2 of 2
- ✓ XCures requery ticket completed (dev env.)
- ✓ Common PSR work — 5 SP completed
Web 1 of 1
- ✓ Wrap-up participant tab and roll out on pre-production server
Org hit rate 66.7%
Down 25 points from S2 and 12 below the PI 10 average. Three of the four misses are release-stage: Data's 1.2.0 to pre-prod, Mobile's 6.4.2.0 release, and Mobile's TLA-202 switching. The goals that were hit are almost all development-stage — merged, completed, running in a dev or pre-prod environment.
Releases
Every version tagged during the sprint, and where it got to. 19 tags across three teams — and none reached production, against three in S2.
| Team | Project | Versions tagged | Count | Furthest environment |
|---|
| Cloud |
cloud-platform-environment | 3.14.0-rc.1 · 3.14.0-rc.2 |
2 | preproduction, 19 & 28 Aug |
| rest-api | 1.221 · 1.222 · 1.223 (.10000) |
3 | component |
| beam-processors | 1.35.2 |
1 | component |
| Data |
data-ecosystem · core · infrastructure | 1.2.0-rc.1 (each) |
3 | release candidate |
| Fusion |
none tagged | — |
0 | — |
| Mobile |
clinical-mobile-app |
6.4.2.0-beta.1 → beta.4 · 6.4.2.0-rc.1 → rc.5 · 6.4.2.0 |
10 | 6.4.2.0 tagged 2 Sep — goal marked missed |
| Web |
none tagged | — |
0 | 8 staging deploys, 0 production |
Everything stopped one step short of production. Cloud cut two release candidates for 3.14.0 and put both into preproduction, but neither went further. Data tagged 1.2.0-rc.1 across all three repos and missed its "Release 1.2.0 on pre-prod" goal. Web ran 8 staging deploys with nothing promoted. Fusion tagged nothing at all.
Mobile is the case worth reading carefully. The 6.4.2.0 tag exists, dated 2 September — the closing day of Mobile's sprint — yet the team marked the "6.4.2.0 release" goal as missed while ticking the release-candidate goal. The tag and the release are not the same event: cutting a version is not the same as getting it in front of users, and the team's own assessment is the more reliable signal here.
Bugs
Bug and Anomaly issues completed in the sprint. Defect work rose to 26, up from 17 in S2 and 33% above the PI 10 average, with Cloud's count jumping from 1 to 8.
Bugs resolved by team
Sprint board figures. The priority column is derived separately — see the note.
| Team | Resolved | PI 10 avg | Δ | High+ by date |
|---|
| Cloud | 8 | 4.2 | ▲ 3.8 | 8 |
| Data | 4 | 4.4 | ▼ 0.4 | 0 |
| Fusion | 0 | 2.0 | ▼ 2.0 | 0 |
| Mobile | 13 | 7.8 | ▲ 5.2 | 1 |
| Web | 1 | 1.2 | ▼ 0.2 | 1 |
| All teams | 26 | 19.6 | ▲ 6.4 | 10 |
Mobile still carries half the load at 13 of 26, but Cloud's jump from 1 to 8 is the change — consistent with its sprint goal to deploy all pen test fixes, which turned security findings into resolved defects.
Read the High+ column with care this sprint. It comes from JIRA resolution dates rather than sprint-board membership, and that population is 38 issues against the boards' 26. Cloud diverges most — 18 by date against 8 on the board — so its 8 High-or-above is drawn from the wider set and is not a subset of the 8 board bugs. The counts and the priority split answer slightly different questions.
Share of the org's bug load
Proportion of the 26 bugs resolved this sprint.
Demand vs Capacity
Commitment plus creep, divided by capacity. Counts everything that landed on a team, however it was labelled. 100% means the team was asked for exactly what it could hold.
Work arriving vs work possible
PI 11 S3 against the PI 10 per-sprint average.
Three sprints, one constant
Why completion and creep are reported as diagnostics, without pass/fail framing.
Across PI 11 the two ratios have swung violently while the underlying volume of work has not moved at all. Demand has read 200%, 204% and 196% of capacity — a 8-point band across three sprints. Over the same period commitment ÷ capacity went 161 → 129 → 150, and the two ratios followed it in opposite directions.
Completion ratio is now at its best of the PI in the same sprint that shipped nothing to production and hit the fewest goals. That is the clearest evidence yet that it is measuring the plan, not the outcome.
| Metric | S1 | S2 | S3 |
|---|
| Demand ÷ capacity | 200% | 204% | 196% |
| Commitment ÷ capacity | 161% | 129% | 150% |
| Completion ratio | 37.8% | 48.1% | 49.9% |
| Creep ratio | 24.4% | 58.4% | 30.9% |
| Velocity ÷ capacity | 83% | 99% | 98% |
| Sprint goals hit | 78.6% | 91.7% | 66.7% |
| Production deploys | 1 | 3 | 0 |
Team scorecard
All deltas are against the PI 10 per-sprint average. Completion and creep levels are shown without status colouring — see the note above.
| Team |
Points |
Demand
÷ Cap |
Completion |
Creep |
MRs Merged |
Bugs |
Goals |
| Cap | Commit | Done |
S3 | Δ |
S3 | Δ |
S3 | Δ |
S3 | Δ |
| Cloud |
26.3 | 61.2 | 29.1 |
278% |
47.5% | ▼ 2.6pp |
19.6% | ▼ 22.8pp |
57 | ▼ 8% |
8 | ▲ 3.8 |
3 / 3 |
| Data |
17.2 | 25.0 | 14.0 |
215% |
56.0% | ▲ 19.4pp |
48.0% | ▼ 77.8pp |
13 | ▼ 45% |
4 | ▼ 0.4 |
0 / 2 |
| Fusion |
19.8 | 24.0 | 6.5 |
141% |
27.1% | ▼ 36.4pp |
16.7% | ▼ 9.6pp |
8 | ▼ 64% |
0 | ▼ 2.0 |
2 / 2 |
| Mobile |
27.6 | 43.0 | 17.5 |
224% |
40.7% | ▲ 1.6pp |
43.8% | ▲ 19.0pp |
97 | ▲ 59% |
13 | ▲ 5.2 |
2 / 4 |
| Web |
31.8 | 30.5 | 24.5 |
127% |
80.3% | ▲ 35.0pp |
32.8% | ▼ 88.9pp |
19 | ▼ 4% |
1 | ▼ 0.2 |
1 / 1 |
| All teams | 122.7 | 183.7 | 91.6 |
196% |
49.9% | ▲ 3.5pp |
30.9% | ▼ 22.0pp |
194 | ▲ 3% |
26 | ▲ 6.4 |
8 / 12 |
Output per engineer
Normalised by delivery roster so a 4-person team can be read against a 9-person one. The index compares each team to its own PI 10 per-engineer average, where 100 means unchanged — the only cross-team-safe comparison here, because story points are not a common currency between teams.
Per-engineer output, PI 11 S3
Delivery roster is engineers, QE and interns; PMO and Product Owners excluded.
| Team | Roster | Velocity
/eng | Index | MRs
/eng | Index |
|---|
| Cloud6 eng |
6 | 6.0 | 115 | 9.5 | 92 |
| Data2 eng · 1 QE · 1 intern |
4 | 4.8 | 144 | 3.3 | 77 |
| Fusion4 eng |
4 | 1.9 | 34 | 2.0 | 36 |
| Mobile6 eng · 3 QE |
9 | 3.0 | 86 | 10.8 | 159 |
| Web5 eng · 1 QE |
6 | 5.1 | 136 | 3.2 | 96 |
| All teams23 eng · 5 QE · 1 intern |
29 | 4.1 | 101 | 6.7 | 109 |
Commits per engineer: Mobile 157, Cloud 90, Data 34, Web 24, Fusion 17. Roster is unchanged at 29. Mobile gained a member on 1 September, two days before its sprint closed; that person is excluded here on the same basis as Data's departures in S2, so the denominator stays comparable.
Org output per head is steady for a second sprint — 101 on points and 109 on MRs, against 104 and 101 in S2.
Per-engineer index vs own PI 10 baseline
100 = each team's own PI 10 per-engineer average. Above the line is more output per head than usual.
Fusion is now down on both measures at once — 34 on points and 36 on MRs, the lowest pair recorded by any team this PI. Its MR index has fallen for four consecutive sprints (100 → 71 → 31 → 36) and the points measure has now followed. This is no longer a single soft metric.
Data's 144 on points comes with an MR index of 77, a much narrower gap than S2's 198 against 24 — the team is producing again, not only closing out work in flight.
Per-team read
One paragraph each, anchored to the numbers above.
Cloud Strong sprint, stalled at the last step
Hit 3 of 3 goals, completed 29.1 points at 137% of capacity, and cleared its pen test backlog — which is why bugs jumped from 1 to 8. But the two 3.14.0 release candidates it cut both stopped in preproduction, so for the first sprint this PI it put nothing into production. Its release-cadence goal now stands at 2 platform releases across 3 active sprints.
Completion 47.5%Velocity 36.1 = 137% of capGoals 3/3Prod deploys 0
Data Output recovered, both goals missed
Activity came back on a 4-person roster — 13 MRs against 4 in S2, 136 commits against 25 — and completion of 56% is 19 points above its own PI 10 average. But it missed both sprint goals, the first zero-goal sprint by any team this PI: 1.2.0 was tagged as rc.1 across all three repos but never reached pre-prod, and the Web scheduled-task assets were not completed.
Completion 56.0% ▲19.4ppMRs 13 ▲9 vs S2Goals 0/21.2.0 rc.1
Fusion Fourth decline, now across the board
Completed 6.5 of 24 committed points — 27.1%, its lowest of the PI — on a velocity of 7.5 against 19.8 of capacity, just 38%. It tagged no releases and merged 8 MRs, 64% below its PI 10 average. It did hit both sprint goals, and demand at 141% was the lightest of any team, so this is not an overload story. Both per-engineer measures are now in the mid-30s.
Completion 27.1% ▼36.4ppVelocity 7.5 = 38% of capMRs 8 ▼64%Goals 2/2
Mobile Highest activity, half the goals
The most active team by a wide margin: 97 MRs merged, up 59% on its PI 10 average and its highest of the PI, with 1,412 commits. It cut nine 6.4.2.0 pre-release versions and tagged the final on the sprint's closing day, but marked the release goal missed along with TLA-202 Safety Careplan switching. It also absorbed the most unplanned work of any team — 18.85 points, a 43.8% creep ratio — and resolved 13 bugs, half the org total.
MRs 97 ▲59%Creep 43.8% ▲19ppBugs 13Goals 2/4
Web Cleanest sprint of the PI
Completed 24.5 of 30.5 committed points — 80.3%, the only team to clear the old 80% completion mark all PI — with velocity at 96% of capacity and demand at 127%, the closest any team came to a plan that matched its capacity. It hit its goal, rolling the participant tab out to pre-production. Nothing was promoted to production, and it tagged no versions, but after two sprints at 10 and 18 points of commitment this is the first time it planned near its own size and delivered on it.
Completion 80.3% ▲35ppDemand 127%Velocity 30.5 = 96% of capGoals 1/1
Delivery flow & 2026 goals
DORA targets are ≥ 0.5 deploys per day and a median lead time under 7 days. Only Cloud and Web have production environments mapped; Mobile has testing channels only; Data and Fusion have a dev environment only.
Production pipeline
PI 11 S3, against the PI 10 per-sprint average.
| Team | Prod
deploys | Δ vs
PI 10 | Per
day | Staging | Median
lead time |
|---|
| Cloud |
0 | ▼ 0.4 | 0.00 | 2 | — |
| Web |
0 | ▼ 0.8 | 0.00 | 8 | — |
| Mobile |
n/a | — | — | 0 test | — |
| Tracked teams | 0 | ▼ 1.2 | 0.00 | 10 | — |
No production deployment reached any environment this sprint — the first such sprint in the six-sprint window. Ten staging deploys happened, so the pipeline is not blocked at build or test; the stall is at the promotion step. Lead time cannot be computed at all, because it is measured from commit to production deploy and there were none. Data and Fusion have no production or staging environments mapped.
2026 goal progress
Rate-based goals exclude the IP sprint.
| Goal | S3 status |
|---|
| All leads · sprint goal hit rate ≥ 80% | 66.7% — missed, down from 91.7% in S2 |
| Cloud · 1 platform release per active sprint | 0 this sprint — 2 in 3 active sprints, now behind pace |
| Mobile · ~3 unique RC versions per PI | 3 reached (6.4.0.0, 6.4.0.1, 6.4.2.0) — target met at S3 |
| Data, Fusion, Web · goals are Jira deliverables | Not tracked in the warehouse |
The shared goal moved from met to missed in a single sprint, and Cloud's release cadence slipped behind because 3.14.0 stopped in preproduction. Mobile's RC target was reached by S2 and has now been exceeded, which continues to suggest the target is set too low rather than that Mobile is outperforming.
Method. Baseline is the PI 10 per-sprint average over S1 to S5; the IP sprint is excluded so the comparison is against a normal delivery sprint. Ratio aggregates are point-weighted across the PI, not averages of per-sprint ratios. Committed Done is committed work completed at end-of-sprint estimate, not total resolved work; Velocity is Committed Done plus Creep Done. Commitment uses each issue's estimate at sprint start, so punted work still counts against it. Demand vs Capacity is commitment plus creep over capacity. Completion Ratio and Creep Ratio are shown as diagnostics without pass/fail colouring: both divide by commitment, which the team sets, so their levels are not comparable across teams or against a fixed target. MR and commit counts attribute to the author's team, not the repository, and each team is measured over its own sprint dates; commit counts include automation and release traffic and are the noisier of the two activity measures. Per-engineer figures use the delivery roster — engineers, QE and interns, excluding PMO and Product Owners — 29 people this sprint. Releases and deployments are counted in each team's own sprint window and exclude the boundary date shared with the previous sprint, so nothing is double-counted; a tag is not a release, and the furthest-environment column cross-checks against deployment records. Bug counts are the sprint board figures; the High-or-above column is derived from JIRA resolution dates over a population of 38 issues against the boards' 26, so the two columns are not strict subsets — Cloud diverges most. PI 11 S4 opened on 1 to 3 September and is excluded.