Sprint Report · PI 11 · Sprint 3
Mobile
19 August – 2 September 2026 PMA Mobile PIQ PI11S3
The busiest sprint of the PI, and the release goal still marked missed
97 merge requests merged, more than any sprint in PI 10 or PI 11, and velocity at 27 points, 98% of capacity. Ten tags were cut for one version: four betas, five release candidates and the 6.4.2.0 final tag on 2 September, the sprint's closing day. The team marked the release goal missed even so. Defect work stayed high at 13 resolved.
The sprint at a glance
Every comparison on this page is against Mobile's own PI 10 per‑sprint average over S1–S5. The IP sprint is excluded so the baseline is a normal delivery sprint.
Velocity vs Capacity
98%
27 of 27.6 points resolved · 105% average in PI 10
Sprint Goals Hit
2 / 4
50% this sprint · 5 of 10 across PI 11
Demand vs Capacity
224%
commitment plus unplanned work · 247% average in PI 10
Merge Requests Merged
97
110 opened · 61 per sprint in PI 10
Defects Resolved
13
bugs and anomalies · 7.8 per sprint in PI 10
Versions Tagged
4
in the sprint window
Sprint goals
Every goal exactly as written on the board, with the team's own assessment at sprint close.
- ✗6.4.2.0 release
- ✓6.4.2.0 Release Candidate
- ✓ePRO Branching logic
- ✗TLA-202 Safety Careplan switching
How the last nine sprints look
PI 10 S1 through PI 11 S3. The PI 10 IP sprint is shown for completeness but excluded from every average on this page.
Capacity, commitment and velocity
Story points. Capacity is the target the team set; commitment is what was taken on at sprint start; velocity is everything resolved, planned or not.
Demand vs capacity
Commitment plus unplanned work, over capacity. 100% means the team was asked for what it could hold.
Sprint goal hit rate
Goals ticked over goals set. The dashed line is the shared 80% target.
Merge requests merged
Attributed by author's team, not by repository. A volume signal, not a productivity measure.
Defects resolved
Bug and Anomaly issues completed in the sprint: a deviation from spec, whatever its cause.
Where the work got to
Versions tagged inside the sprint window, and how far they travelled.
| Project | Version | Tagged | What it was |
|---|
| clinical-mobile-app | 6.4.0.1-rc.1.0 | 19 Aug | release candidate |
| clinical-mobile-app | 6.4.2.0-beta.1.0 → beta.4.0 | 20–26 Aug | 4 beta tags |
| clinical-mobile-app | 6.4.2.0-rc.1.0 → rc.5.0 | 27 Aug – 1 Sep | 5 release candidates |
| clinical-mobile-app | 6.4.2.0 | 2 Sep | final tag, release goal marked missed |
Deployments by environment
Deployment tracking is not configured for Mobile, so deployment frequency and lead time cannot be reported. Release tags are the only pipeline signal available.
Planning diagnostics
Completion ratio and creep ratio are shown here without pass or fail framing, and deliberately not as tiles.
| Sprint | Capacity | Commitment | Completion | Creep | Demand ÷ cap |
|---|
| S1 | 28.6 | 64 | 31.2% | 19% | 266% |
| S2 | 32.2 | 56 | 45.5% | 19% | 207% |
| S3 | 27.6 | 43 | 40.7% | 44% | 224% |
| PI 10 avg | 30 | 59.5 | 39.1% | 25% | 247% |
Why these are diagnostics, not targets. Completion ratio is committed work done over commitment, so it moves when the plan changes even if the work does not. Across PI 11 the volume of work arriving has been close to flat while these two ratios have swung widely, in opposite directions. They are useful for a conversation about how the plan is set. They are not a measure of how much the team did. Velocity against capacity, sprint goals, and what actually reached an environment are the outcome measures on this page.
2026 goal progress
Team goals from the 2026 engineering goals document, measured where the warehouse can measure them.
| Goal | Target | PI 11 to date | Status |
|---|
| Sprint goal achievement | ≥ 80% hit rate | 5 of 10 goals hit across PI 11 (50%) | Below target |
| Release Candidate cadence | 1 RC every 2 sprints (~3 per PI) | 3 unique RC versions across S1–S3 (6.4.0.0, 6.4.0.1, 6.4.2.0) | On track |
For the conversation
Three questions the data raises. They are questions, not conclusions: the team knows things the warehouse does not.
1
Ten tags for one version
Four betas and five release candidates preceded 6.4.2.0. Each iteration was presumably catching something. What is being found late in that cycle, and what would it take to find it one stage earlier?
2
Where is the line between tagged and released?
6.4.2.0 was tagged on the sprint's closing day and the team still marked the release goal missed, which reads as the honest call. Should the goal name the thing that actually matters (in front of users, store submission, approval) so the tag and the goal can't disagree?
3
13 defects alongside 97 merges
Defect work has run at 16, 11 and 13 resolved across the PI. Is that arriving as escaped defects from earlier releases, or is it planned hardening? The answer changes whether the number is a warning or a plan.
How to read this
Source: the prolaio-engineering-metrics warehouse (JIRA boards, GitLab releases and deployments, GitLab merge-request events). Commitment is measured at each issue's estimate at sprint start; committed-done, creep and creep-done at the estimate at sprint close, so work re-sized mid-sprint counts at its real size. Velocity is committed-done plus creep-done. Defects count completed Bug and Anomaly issues. Merge requests are attributed to the author's current team. Deployment counts come from the warehouse's per-sprint deployment view and cover every environment mapped to the tier, so a team with several staging environments has them summed; a deployment on a day shared by two sprint windows is assigned to the earlier sprint. PI 11 Sprint 4 opened on 1 September and is excluded throughout.