Product & Engineering Leadership · Weekly · PI 11 Sprint 2
The plan came back to capacity · delivery followed
All five teams for the last closed sprint, 4 to 19 August 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 S3 opened on 18 August and is excluded throughout.
The short version
Commitment fell back to 129% of capacity and almost everything improved. Teams planned 162.2 points against 125.9 of capacity — down from 161% in S1 and level with the PI 10 norm. Velocity reached 98.7% of capacity, the best in six sprints; completion recovered to 48.1%, above the PI 10 average; and
11 of 12 sprint goals were hit — 91.7%, clearing the ≥80% target for the first time in the window, with all three of S1's misses closed out. Creep ratio jumped to 58.4% for the same reason completion improved: the plan shrank while the work did not. Demand held at 204% of capacity against 200% in S1. Same work, different label.
Demand vs Capacity
204%
196% in PI 10 · work arriving
Commitment vs Capacity
129%
128% in PI 10 · 161% in S1
Velocity vs Capacity
99%
96% in PI 10 ▲ 3pp
Sprint Goals Hit
11 / 12
91.7% · target ≥ 80%
Completion Ratio diagnostic
48.1%
46.4% in PI 10 ▲ 1.7pp
Creep Ratio diagnostic
58.4%
52.9% in PI 10 ▲ 5.5pp
Bugs Resolved
17
19.6 in PI 10 ▼ 2.6
Capacity, Commitment, Velocity
PI 11 S2, story points. Velocity sits level with capacity on four of five teams.
Merge Requests Merged
S2 against the PI 10 per-sprint average. Attribution is by author's team, not repository.
Sprint goals
Every goal as written in JIRA. 11 of 12 hit — 91.7%, clearing the ≥80% shared team-lead target, up from 78.6% in S1 and from PI 10's 44 of 56. All three S1 misses were carried into S2 and closed.
Cloud 3 of 3
- ✓ ZBeats PDP — first approval — carried from S1
- ✓ Investigation of Beam Router degradation
- ✓ Pentest findings: everyone contributes at least one ticket
Mobile 2 of 3
- ✓ Release 6.4.0.0 — carried from S1
- ✓ Device Alerts Sync — carried from S1
- ✕ 6.4.2.0 RC
Data 2 of 2
- ✓ DES 1.1.0 technical work done and fully approved
- ✓ Start work on CDS spike about migration
Fusion 3 of 3
- ✓ Development completed for PSR rate limit issue
- ✓ Development completed for XCures external identifier check
- ✓ FE CTRT OCORO tickets complete
Web 1 of 1
- ✓ Resolve issues related to pentest findings
Org hit rate 91.7%
The first sprint in the six-sprint window to clear ≥80%. Cloud closed the ZBeats PDP approval it missed in S1; Mobile closed both of its S1 misses, 6.4.0.0 and Device Alerts Sync. The one remaining miss, Mobile's 6.4.2.0 RC, is the next version in the same line.
Releases
Every version tagged during the sprint, and where it got to. 20 tags across five teams; three reached production, against one in S1. Every team tagged something this sprint.
| Team | Project | Versions tagged | Count | Furthest environment |
|---|
| Cloud |
rest-api |
1.217 · 1.218 · 1.219 · 1.220 (.10000) |
4 | component |
| beam-processors | 1.35.1 |
1 | component |
| cloud-platform-environment | 3.13.0 — tagged in S1 |
— | production, 6 Aug |
| Data |
data-ecosystem | 1.1.0 final |
1 | 1.1.0 released, 13 Aug |
| data-platform-ci | v0.2.4 · v0.2.5 |
2 | tooling |
| Fusion |
pmr-hcm | 4.4.0 · 4.4.1 |
2 | tagged |
| Mobile |
clinical-mobile-app |
6.4.0.0-rc.3 → rc.7 · 6.4.0.0 · 6.4.0.1-rc.1 · 6.4.2.0-alpha.2 · alpha.3 |
8 | 6.4.0.0 final cut, 14 Aug |
| Web |
prolaio-workbench | v1.1.0 |
1 | production, 19 Aug |
| prolaio-web | v1.8.3_carelab |
1 | production, 19 Aug |
Again the releases corroborate the goals. Mobile cut 6.4.0.0 final on 14 August after five more release candidates — the goal it missed in S1, now closed. Data shipped data-ecosystem 1.1.0 final on 13 August, completing the 1.1.0 line that was still at rc.5 when S1 ended. Cloud put platform release 3.13.0 into production on 6 August; it was tagged on 3 August, inside S1, which is why the S1 report showed it as tagged-not-shipped.
Web returned to production after four sprints away — workbench v1.1.0 and carelab v1.8.3 both deployed on 19 August, its first production releases since PI 10 S4. Only Mobile's 6.4.2.0 RC slipped.
Bugs
Bug and Anomaly issues completed in the sprint. Defect work fell 13% against the baseline and 41% against S1, but it concentrated further: Mobile now carries 11 of 17.
Bugs resolved by team
Sprint board figures; the priority split is derived from JIRA resolution dates.
| Team | Resolved | PI 10 avg | Δ | High or above |
|---|
| Cloud | 1 | 4.2 | ▼ 3.2 | 0 |
| Data | 0 | 4.4 | ▼ 4.4 | 0 |
| Fusion | 1 | 2.0 | ▼ 1.0 | 1 |
| Mobile | 11 | 7.8 | ▲ 3.2 | 5 |
| Web | 4 | 1.2 | ▲ 2.8 | 2 |
| All teams | 17 | 19.6 | ▼ 2.6 | 8 |
Mobile's share rose from 55% to 65% even as its absolute count fell from 16 to 11, and 5 of its 11 were High priority or above — the heaviest severity mix in the window. Web's 4 bugs are the pentest findings it took on as a sprint goal, 2 of them High or above. Cloud dropped to a single bug from 6.
Share of the org's bug load
Proportion of the 17 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 S2 against the PI 10 per-sprint average.
This sprint is the seesaw, demonstrated
Why completion and creep are reported as diagnostics, without pass/fail framing.
S1 and S2 are the clearest illustration we have of why these two ratios cannot both be targets. Between them, commitment fell 12% while demand rose slightly — 200% to 204% of capacity. Nothing about the volume of work changed. Yet completion ratio improved 10.3 points and creep ratio worsened 34 points, because both divide by commitment.
Read the pair together and the sprint reads correctly: a plan sized to capacity, throughput at 99% of capacity, and unplanned work absorbed at a rate that shows up as "creep" only because it was never written into the plan. Read either alone and you get the wrong answer.
| Metric | S1 | S2 | Δ |
|---|
| Demand ÷ capacity | 200% | 204% | ▲ 4pp |
| Commitment ÷ capacity | 161% | 129% | ▼ 32pp |
| Completion ratio | 37.8% | 48.1% | ▲ 10.3pp |
| Creep ratio | 24.4% | 58.4% | ▲ 34.0pp |
| Velocity ÷ capacity | 83% | 99% | ▲ 16pp |
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 |
S2 | Δ |
S2 | Δ |
S2 | Δ |
S2 | Δ |
| Cloud |
30.1 | 56.2 | 25.0 |
256% |
44.5% | ▼ 5.6pp |
37.4% | ▼ 5.0pp |
76 | ▲ 23% |
1 | ▼ 3.2 |
3 / 3 |
| Data |
19.5 | 13.0 | 4.0 |
220% |
30.8% | ▼ 5.8pp |
230.8% | ▲ 105pp |
4 | ▼ 83% |
0 | ▼ 4.4 |
2 / 2 |
| Fusion |
13.0 | 27.0 | 16.5 |
277% |
61.1% | ▼ 2.4pp |
33.3% | ▲ 7.0pp |
7 | ▼ 69% |
1 | ▼ 1.0 |
3 / 3 |
| Mobile |
32.2 | 56.0 | 25.5 |
207% |
45.5% | ▲ 6.4pp |
19.2% | ▼ 5.6pp |
83 | ▲ 36% |
11 | ▲ 3.2 |
2 / 3 |
| Web |
31.1 | 10.0 | 7.0 |
109% |
70.0% | ▲ 24.7pp |
240.0% | ▲ 118pp |
10 | ▼ 49% |
4 | ▲ 2.8 |
1 / 1 |
| All teams | 125.9 | 162.2 | 78.0 |
204% |
48.1% | ▲ 1.7pp |
58.4% | ▲ 5.5pp |
180 | ▼ 5% |
17 | ▼ 2.6 |
11 / 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 S2
Delivery roster is engineers, QE and interns; PMO and Product Owners excluded.
| Team | Roster | Velocity
/eng | Index | MRs
/eng | Index |
|---|
| Cloud6 eng |
6 | 5.3 | 102 | 12.7 | 123 |
| Data2 eng · 1 QE · 1 intern |
4 | 6.5 | 198 | 1.0 | 24 |
| Fusion4 eng |
4 | 5.1 | 92 | 1.8 | 31 |
| Mobile6 eng · 3 QE |
9 | 3.4 | 98 | 9.2 | 136 |
| Web5 eng · 1 QE |
6 | 2.5 | 67 | 1.7 | 51 |
| All teams23 eng · 5 QE · 1 intern |
29 | 4.3 | 104 | 6.2 | 101 |
Commits per engineer: Mobile 160, Cloud 116, Fusion 51, Web 16, Data 6. The delivery roster fell from 31 to 29: Data's two departing engineers were on the books for 2 of the sprint's 15 days and are excluded, and the August joiner is a Product Owner, so Data's engineering count went from 4 to 2.
Org per-engineer output is back at baseline on both measures — index 104 on points and 101 on MRs, against 74 and 120 in S1.
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.
Treat Data's 198 on points with caution. It completed 26 points on a 4-person roster, but merged only 4 MRs and pushed 25 commits — an MR index of 24. Twenty-six points on four merge requests is not new build; it reads as closing out work already in flight, including the 1.1.0 approval. The points-per-head figure is arithmetically correct and substantively misleading on its own.
Cloud has converged: 102 on points and 123 on MRs, against 35 and 142 in S1. The split that made it S1's outlier has closed.
Per-team read
One paragraph each, anchored to the numbers above.
Cloud Recovered on every measure
The sharpest turnaround in the sprint. Completion nearly doubled from 25.5% to 44.5%, velocity went from 11 points to 32 — 106% of capacity — and it hit 3 of 3 goals including the ZBeats PDP approval it missed in S1. Platform release 3.13.0 reached production on 6 August and median lead time halved from 25 days to 13. Its per-engineer split, 35 on points against 142 on MRs in S1, closed to 102 and 123.
Completion 44.5% ▲19pp vs S1Velocity 32 = 106% of capMRs 76 ▲23%Lead time 13 d ▼12 d
Data Shipped 1.1.0 on a halved roster
Delivered both sprint goals and cut data-ecosystem 1.1.0 final on 13 August, completing a line that was still at rc.5 when S1 closed. It did so with 2 engineers, down from 4: the two departures at the start of the sprint. Activity collapsed accordingly — 4 MRs merged against a PI 10 average of 23.6, and 25 commits against 291. The 26 points of velocity came almost entirely from creep (22 of 26) on a 13-point plan, which is why creep ratio reads 231%.
Goals 2/21.1.0 finalMRs 4 ▼83%Engineers 2
Fusion Third straight sprint of cooling activity
Goals and completion held — 3 of 3 and 61.1%, both consistent with its own history — and velocity of 20.5 was 158% of a capacity that dropped to 13 points. But activity fell again: 7 MRs merged against a PI 10 average of 22.4, an index of 31, its lowest in the window and the third consecutive decline. Demand hit 277% of capacity, the highest of any team.
Completion 61.1% ▼2.4ppDemand 277%MRs 7 ▼69%Goals 3/3
Mobile Cut 6.4.0.0 · still carries the defects
Closed both S1 misses: 6.4.0.0 went final on 14 August after five further release candidates, and Device Alerts Sync landed. Completion improved to 45.5%, above its own PI 10 average, on the highest activity in the org — 83 MRs merged and 1,436 commits. It remains the defect sink: 11 of the org's 17 bugs, 65% of the total, with 5 at High priority or above. The one goal miss, 6.4.2.0 RC, is the next version in the same line.
6.4.0.0 finalCompletion 45.5% ▲6.4ppMRs 83 ▲36%Bugs 11 · 5 High+
Web Back in production, on a very small plan
Shipped two production releases on 19 August — workbench v1.1.0 and carelab v1.8.3 — its first since PI 10 S4, and cleared its pentest-findings goal. Completion of 70% is the highest of any team. But it committed only 10 points against 31.1 of capacity and then absorbed 24 points of unplanned work, so 240% creep and 109% demand describe a sprint that was almost entirely unplanned. Median lead time to production came in at 53 days, the longest measured this PI, reflecting how long those commits had been waiting.
Prod releases 2Completion 70.0% ▲24.7ppCreep 240%Lead time 53 d
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 S2, against the PI 10 per-sprint average.
| Team | Prod
deploys | Δ vs
PI 10 | Per
day | Staging | Median
lead time |
|---|
| Cloud |
1 | ▲ 0.6 | 0.07 | 0 | 13 d |
| Web |
2 | ▲ 1.2 | 0.15 | 3 | 53 d |
| Mobile |
n/a | — | — | 0 test | — |
| Tracked teams | 3 | ▲ 1.8 | 0.11 | 3 | — |
Three production deployments against one in S1 and 1.2 per sprint across PI 10. Cloud's median lead time halved from 25 days to 13 — the best figure this PI, still nearly double the 7-day target. Web's 53 days is its first measurement since PI 10 and the longest in the window; both its releases carried commits that had been sitting for weeks. Deployment frequency remains far below 0.5/day for both teams. Data and Fusion have no production or staging environments mapped.
2026 goal progress
Rate-based goals exclude the IP sprint.
| Goal | S2 status |
|---|
| All leads · sprint goal hit rate ≥ 80% | 91.7% — met, first time this PI |
| Cloud · 1 platform release per active sprint | 3.13.0 to production 6 Aug — 2 in 2 active sprints, on pace |
| Mobile · ~3 unique RC versions per PI | 3 so far (6.4.0.0, 6.4.0.1, 6.4.2.0) — target met with four sprints left |
| Data, Fusion, Web · goals are Jira deliverables | Not tracked in the warehouse |
Two of the three warehouse-tracked goals moved forward this sprint and the shared goal was met. Mobile has now reached its full-PI RC target by S2, which suggests the target is set too low rather than that Mobile is exceptional — worth revisiting at PI planning.
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, down from 31 in S1. Releases are counted in each team's own sprint window, so a version tagged on a boundary date is attributed to one sprint only; a tag is not a release, and the furthest-environment column cross-checks against deployment records. Bug counts are the sprint board figures; the priority split is derived from JIRA resolution dates and may differ by one or two. PI 11 S3 opened on 18 to 19 August and is excluded.