Product & Engineering Leadership · Weekly · PI 11 Sprint 1
Activity went up · the board went down
All five teams for the last closed sprint, 22 July to 5 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 S2 was still in flight when this was generated and is excluded throughout.
The short version
Capacity fell 13%, the plan grew 9%, and merge throughput rose 21%. Available capacity dropped from 131.6 to 114.1 points, but commitment rose from 168.4 to 183.7 — so teams planned 161% of what they had, against 128% in PI 10. Completion fell 8.6 points to 37.8%. The repositories say the opposite: 229 merge requests merged, up 21% on the PI 10 sprint average, and 3,072 commits, up 47%. The engineering was not slower this sprint. The gap is between what the teams did and what the board says they committed to.
Demand vs Capacity
200%
196% in PI 10 · work arriving
Commitment vs Capacity
161%
128% in PI 10 ▲ 33pp
MRs Merged
229
189 in PI 10 ▲ 21%
Sprint Goals Hit
11 / 14
78.6% · target ≥ 80%
Completion Ratio diagnostic
37.8%
46.4% in PI 10 ▼ 8.6pp
Creep Ratio diagnostic
24.4%
52.9% in PI 10 ▼ 28.5pp
Bugs Resolved
30
19.6 in PI 10 ▲ 10.4
Capacity, Commitment, Velocity
PI 11 S1, story points. Every team except Web committed above capacity.
Merge Requests Merged
S1 against the PI 10 per-sprint average. Attribution is by author's team, not repository.
Sprint goals
Every goal as written in JIRA, with the team's own stated reason for a miss. 11 of 14 hit — 78.6%, against the ≥80% shared team-lead target, unchanged from PI 10's 44 of 56.
Cloud 3 of 4
- ✓ Deploy release 3.12.x
- ✓ Deliver the Kardigan EDC backfills
- ✓ Improve the lag situation from where it is now
- ✕ ZBeats PDP (first approval)
Mobile 1 of 3
- ✓ Prevent language selection
- ✕ 6.4.0.0 release — features got delayed
- ✕ BYOD device alert synchronization — waiting on MR approval
Data 2 of 2
- ✓ DES Release 1.1.0 — to have RC
- ✓ Temporary solution for special access to production
Fusion 3 of 3
- ✓ PSR v2 project is made in PSR repo
- ✓ X-Cures JIRA project is created and set
- ✓ CTRT FE infrastructure ready for production
Web 2 of 2
- ✓ Dev complete (at least MR review) for REST API listing Orgs for a User
- ✓ Define requirements for v1 Clinical Reporting Tool
Org hit rate 78.6%
1.4 points short of the ≥80% shared target. Both misses outside Cloud belong to Mobile, which has now been below 50% on sprint goals for two sprints running.
Releases
Every version tagged during the sprint, and where it got to. 23 tags across three teams; one reached production. Counted in each team's own sprint window.
| Team | Project | Versions tagged | Count | Furthest environment |
|---|
| Cloud |
cloud-platform-environment |
3.12.2 · 3.12.3 · 3.13.0-rc.1 · 3.13.0-rc.2 · 3.13.0 |
5 | 3.12.2 → production, 28 Jul |
| beam-processors | 1.36.0 · 1.37.0 |
2 | component |
| rest-api | 1.216.10000 |
1 | component |
| Data |
data-ecosystem | 1.1.0-rc.1 → rc.5 |
5 | release candidate |
| data-ecosystem-core | 1.1.0-rc.2 → rc.5 |
4 | release candidate |
| data-ecosystem-infrastructure | 1.0.1-rc.1 · rc.2 |
2 | release candidate |
| Fusion |
none tagged | — |
0 | pmr-hcm 4.4.0 was tagged 5 Aug, in S2 |
| Mobile |
clinical-mobile-app |
6.4.0.0-rc.1.0 · 6.4.0.0-rc.2.0 · 6.4.2.0-alpha.1.0 |
3 | release candidate |
| health-devices-ble-library | 2.18.0 |
1 | library |
| Web |
none tagged | — |
0 | 9 staging deploys, 0 production |
The releases corroborate the sprint goals exactly. Cloud hit "Deploy release 3.12.x" — 3.12.2 went to preproduction on 23 July and production on 28 July, and 3.13.0 was cut on 3 August but only reached production on 6 August, inside S2. Data hit "DES Release 1.1.0 — to have RC" with eleven RC tags across three repos, reaching 1.1.0-rc.5. Mobile missed "6.4.0.0 release" — two release candidates were cut on 4 and 5 August but no final version, which matches the team's own note that features got delayed.
Cloud is the only team whose work reached production this sprint. Data and Mobile both stopped at release candidate, and Web tagged nothing at all.
Bugs
Bug and Anomaly issues completed in the sprint. Defect work grew 53% against the baseline while story-point completion fell.
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 | 6 | 4.2 | ▲ 1.8 | 2 |
| Data | 7 | 4.4 | ▲ 2.6 | 1 Critical |
| Fusion | 1 | 2.0 | ▼ 1.0 | 1 |
| Mobile | 16 | 7.8 | ▲ 8.2 | 1 |
| Web | 0 | 1.2 | ▼ 1.2 | 0 |
| All teams | 30 | 19.6 | ▲ 10.4 | 5 |
Mobile alone accounts for 8.2 of the 10.4 increase. The warehouse holds no open-bug backlog, so inflow and ageing cannot be measured yet.
Share of the org's bug load
Proportion of the 30 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 S1 against the PI 10 per-sprint average.
How to read Completion and Creep
Both are shown as diagnostics, without pass/fail framing.
Both targets exist to push teams toward better planning and predictable delivery. That intent is right and the problem is real — but these two ratios cannot measure it, because they share a denominator the team sets itself: commitment. To hit completion ≥ 80% you commit less; to hit creep ≤ 20% you commit more. Across PI 8 to PI 11 S1, no sprint has ever hit both — 0 of 93, with six hitting completion and thirty-eight hitting creep.
And it is not only gaming. In the 20 sprints where commitment sat within 80–120% of capacity — honest plan sizes, nothing to manipulate — completion was still 50% and creep still ran at a median of 52%. The unpredictability is genuine; completion ratio simply cannot diagnose it.
| Carries the same intent | Now |
|---|
| Sprint goal achievement | 78.6% |
| Forecast error vs own throughput | 35% |
| Demand vs capacity | 200% |
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 |
S1 | Δ |
S1 | Δ |
S1 | Δ |
S1 | Δ |
| Cloud |
26.8 | 43.2 | 11.0 |
176% |
25.5% | ▼ 24.6pp |
9.3% | ▼ 33.1pp |
88 | ▲ 42% |
6 | ▲ 1.8 |
3 / 4 |
| Data |
16.7 | 31.0 | 12.0 |
277% |
38.7% | ▲ 2.1pp |
49.2% | ▼ 76.6pp |
29 | ▲ 23% |
7 | ▲ 2.6 |
2 / 2 |
| Fusion |
19.7 | 27.5 | 16.5 |
188% |
60.0% | ▼ 3.5pp |
34.5% | ▲ 8.2pp |
16 | ▼ 29% |
1 | ▼ 1.0 |
3 / 3 |
| Mobile |
28.6 | 64.0 | 20.0 |
266% |
31.3% | ▼ 7.8pp |
18.8% | ▼ 6.0pp |
90 | ▲ 48% |
16 | ▲ 8.2 |
1 / 3 |
| Web |
22.3 | 18.0 | 10.0 |
99% |
55.6% | ▲ 10.3pp |
22.2% | ▼ 99.5pp |
6 | ▼ 70% |
0 | ▼ 1.2 |
2 / 2 |
| All teams | 114.1 | 183.7 | 69.5 |
200% |
37.8% | ▼ 8.6pp |
24.4% | ▼ 28.5pp |
229 | ▲ 21% |
30 | ▲ 10.4 |
11 / 14 |
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 S1
Delivery roster is engineers, QE and interns; PMO and Product Owners excluded.
| Team | Roster | Velocity
/eng | Index | MRs
/eng | Index |
|---|
| Cloud6 eng |
6 | 1.8 | 35 | 14.7 | 142 |
| Data4 eng · 1 QE · 1 intern |
6 | 3.0 | 93 | 4.8 | 115 |
| Fusion4 eng |
4 | 5.6 | 101 | 4.0 | 71 |
| Mobile6 eng · 3 QE |
9 | 3.2 | 92 | 10.0 | 148 |
| Web5 eng · 1 QE |
6 | 2.3 | 63 | 1.0 | 30 |
| All teams25 eng · 5 QE · 1 intern |
31 | 3.1 | 74 | 7.4 | 120 |
Commits per engineer: Mobile 201, Cloud 134, Data 47, Fusion 29, Web 10. One PMO member is recorded against Cloud, Data and Fusion simultaneously in the warehouse and is excluded from all three. QE stay in the denominator because completing a story is QE work as much as dev work.
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.
Role mix is not comparable either: Fusion is all engineers, Mobile runs 6 engineers to 3 QE — the heaviest quality investment in the org, worth holding next to its bug load. Fusion leads on points per head at 5.6, but read that as a within-team trend rather than a ranking: capacity per engineer ranges from 2.8 on Data to 4.9 on Fusion, a difference in estimation scale, not hours available.
Cloud is the outlier on both measures at once — 35 on points per engineer, 142 on MRs per engineer. No other team splits that far.
Per-team read
One paragraph each, anchored to the numbers above.
Cloud Busy, but not on the board
Merged 88 MRs — 42% above its PI 10 average and the most of any team bar Mobile — and shipped platform release 3.12.2. Committed points barely moved: 11 of 43.2. Creep was only 9.3%, its cleanest sprint for unplanned work, so interruption is not the explanation. Activity and board progress point in opposite directions.
Completion 25.5% ▼24.6ppMRs 88 ▲42%Commits 804 ▲54%Goals 3/4
Data Plan discipline recovering
The biggest improvement in planning quality: creep fell from 125.8% to 49.2% — unplanned work used to exceed the entire plan. Completion edged up to 38.7% and both sprint goals were hit. Still commits 186% of capacity, and resolved 7 bugs including one Critical, up from an average of 4.4.
Completion 38.7% ▲2.1ppCreep 49.2% ▼76.6ppMRs 29 ▲23%Goals 2/2
Fusion Steadiest, but cooling
Highest completion ratio in the org at 60%, 3 of 3 sprint goals, and a single bug. It is also the only team where every activity measure fell — 16 MRs merged, down 29%, and 116 commits, down 23% — while creep rose to 34.5%, its third consecutive increase.
Completion 60.0% ▼3.5ppCreep 34.5% ▲8.2ppMRs 16 ▼29%Goals 3/3
Mobile Most output, least plan accuracy
The most active team by a distance: 90 MRs merged (up 48%), 1,809 commits, and 16 bugs resolved — more than double its average and over half the org's total. Yet it hit 1 of 3 sprint goals and completed 31.3% of a commitment set at 224% of capacity. 6.4.0.0 slipped on delayed features; BYOD alert sync is blocked on MR approval.
Completion 31.3% ▼7.8ppCommit/cap 224%MRs 90 ▲48%Bugs 16
Web Best plan, lowest activity
The only team to commit under capacity, and it shows: completion improved most in the org, up 10.3 points to 55.6%, and creep collapsed from 121.7% to 22.2%. But it did so on the smallest plan at 18 points, with activity well down — 6 MRs merged against an average of 19.8, and 62 commits against 296. Zero production deploys, as in every sprint since PI 10 S4.
Completion 55.6% ▲10.3ppMRs 6 ▼70%Commits 62 ▼79%Prod deploys 0
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 S1, 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 | 3 | 25 d |
| Web |
0 | ▼ 0.8 | 0.00 | 6 | — |
| Mobile |
n/a | — | — | 0 test | — |
PI 10 per-sprint averages: Cloud 0.4 and Web 0.8 production deploys, Mobile 1.2 testing releases. Web has run zero production deploys since PI 10 S4; its last measured median lead time was 24 days. Data and Fusion have no production or staging environments mapped.
2026 goal progress
Rate-based goals exclude the IP sprint.
| Goal | S1 status |
|---|
| All leads · sprint goal hit rate ≥ 80% | 78.6% — at risk, 1.4pp short |
| Cloud · 1 platform release per active sprint | 1 (3.12.2, 28 Jul) — on pace after a PI 10 miss, 2 in 5 |
| Mobile · ~3 unique RC versions per PI | 1 so far (6.4.0.0) — on pace |
| Data, Fusion, Web · goals are Jira deliverables | Not tracked in the warehouse |
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 — 31 people, not the 36 memberships the warehouse holds. 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 S2 was in flight when this was generated, closing 18 to 19 August, and is excluded.