Engineering Performance · PI 10 brief
PI 10 · Mobile
PI 10 ran 28 April to 5 August 2026. This brief summarises Mobile's PI 10 results across the five active sprints. The IP sprint (S6) is excluded from headline metrics per the standard convention.
Mobile halved its bug count in PI 10: 39 completed against 76 in PI 9 and 80 in PI 8, the lowest since PI 7. Creep Ratio came down to 25% from 40%, the team's best planning result since PI 6. Four unique release candidates shipped against a target of roughly three, and nine final releases landed across three projects. Merged MR throughput finished 20% above the PI 8 baseline.
Completion Ratio
39%
▼ -17pp vs PI 9 (56.1%)
Committed Done vs Capacity
78%
▼ -10pp vs PI 9 (88.3%)
Velocity vs Capacity
106%
▼ -28pp vs PI 9 (133.3%)
Sprint Goals Hit
78%
7 of 9 goals
Creep Ratio
25%
▲ -15pp vs PI 9 (40.2%)
Bugs Completed
39
▲ -37 vs PI 9 (76)
Merged MRs
292
▲ +20% vs PI 8 · 4.1/day
Capacity, Commitment, Velocity, Creep · PI-level
Story points per PI · velocity = commit_done + creep_done · creep shown as absolute SP
Capacity
Commitment
Velocity
Creep
Capacity, Commitment, Velocity, Creep · PI 10 by sprint
All six sprints actual. S6 is the IP sprint and is excluded from the headline metrics above.
Capacity
Commitment
Velocity
Creep
Creep Ratio · PI-level
creep / commitment · 20% ceiling shown
Creep ratio
20% ceiling
Bugs Completed · PI-level
Count per PI
Bugs
Release activity · PI-level
Counts from GitLab releases · finals (no suffix) and unique RC versions
Final releases
Unique RC versions
Merged MRs and commits · PI-level activity
Accepted merge requests and commits per PI, attributed by team member, active sprints only. PI 9 was a broad-based activity peak across the whole organisation.
Merged MRs
Commits (right axis)
Final releases this PI
Final releases shipped in PI 10. RC, alpha and beta tags excluded.
| Date | Project | Version |
|---|
| 28 Apr | clinical-mobile-app | 6.3.22.0 |
| 1 May | health-devices-ble-library | 2.17.0 |
| 13 May | clinical-mobile-app | 6.3.24.0 |
| 1 Jun | clinical-mobile-app | 6.3.25.0 |
| 8 Jun | prolaio-monitor | 1.0.1 |
| 9 Jun | prolaio-monitor | 1.0.2 |
| 9 Jun | prolaio-monitor | 1.0.3 |
| 10 Jun | prolaio-monitor | 1.0.4 |
| 15 Jun | clinical-mobile-app | 6.3.26.0 |
Goal progress
Result against 2026 team-level engineering goals applicable to Mobile · status reflects the final PI 10 position.
Sprint & PI goal achievement
78% · 7 of 9 goals across S1-S5
Target: ≥ 80% (shared, all teams)
Miss · marginal
Release candidate cadence
4 unique RC versions (6.3.24.0, 6.3.25.0, 6.3.26.0, 6.3.28.0)
Target: ~3 RCs per PI (Kartik)
Pass
What stood out
Bug count fell to 39 from 76 in PI 9 and 80 in PI 8. This is the lowest bug count Mobile has recorded since PI 7 and roughly half the level of the previous two PIs.
Creep Ratio came down to 25% from 40% in PI 9 and 32% in PI 8. Creep rose to 40% in PI 9 before falling to 25% in PI 10, the lowest reading since PI 6.
Four unique release candidates shipped (6.3.24.0, 6.3.25.0, 6.3.26.0, 6.3.28.0), exceeding the roughly-three-per-PI target. Nine final releases landed across clinical-mobile-app, health-devices-ble-library and prolaio-monitor.
Velocity vs Capacity finished at 106%. Total resolved work continues to run above measured capacity.
Merged MRs finished at 292 against 243 in PI 8, up 20%. Mobile carries by far the highest review volume of any team at 918 approvals, roughly 3.1 per merge, against an organisation average of 2.0.
Where the data is mixed
Commitment rose to 199% of capacity, up from 158% in PI 9 and the second highest in the trend window. Mobile committed 297.3 SP against 149 SP of measured capacity. The 39% Completion Ratio is a direct consequence of that gap rather than a delivery problem: the team resolved 157.5 SP, which is more than its capacity.
Sprint goal hit rate finished at 78%, just under the 80% target. Two goals went unmet in S4 (release candidate 6.3.28.0, and device alerts syncing for BYOD). S5 recorded no parseable goals at all.
Velocity fell from 208 SP in PI 9 to 157.5 SP, a 24% drop, while capacity was broadly flat. PI 9 was an unusually high output PI, so this reads as a return to the PI 8 level rather than a decline from a stable baseline. The same shape appears in activity: 836 merged MRs in PI 9 against 243 in PI 8 and 292 in PI 10. PI 9 was an organisation-wide peak rather than a Mobile-specific one, so both the velocity and the activity figures read as a return toward baseline rather than a decline from a stable level.