Sprint Report · PI 11 · Sprint 3
Cloud
19 August – 1 September 2026 CLOUD PI11S3
Strongest sprint of the PI, and the plan is now 2.3× the capacity
All three sprint goals hit for the second sprint running, and 36.1 points resolved against a capacity of 26.3. That is the highest velocity of PI 11. At the same time commitment has climbed every sprint, 43.2 to 56.2 to 61.2 points, while capacity has not. 3.14.0 reached rc.2 in preproduction and stopped there, so nothing went to production this sprint. Bug work rose from 1 to 8 as the pen test fixes landed.
The sprint at a glance
Every comparison on this page is against Cloud'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
137%
36.1 of 26.3 points resolved · 96% average in PI 10
Sprint Goals Hit
3 / 3
100% this sprint · 9 of 10 across PI 11
Demand vs Capacity
278%
commitment plus unplanned work · 167% average in PI 10
Merge Requests Merged
57
53 opened · 61.8 per sprint in PI 10
Defects Resolved
8
bugs and anomalies · 4.2 per sprint in PI 10
Deployments
0 prod
1 to preproduction · 2 production across S1–S3
Sprint goals
Every goal exactly as written on the board, with the team's own assessment at sprint close.
- ✓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
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 |
|---|
| cloud-platform-environment | 3.14.0-rc.1 | 19 Aug | release candidate, preproduction |
| cloud-platform-environment | 3.14.0-rc.2 | 28 Aug | release candidate, preproduction |
| beam-processors | 1.35.1 | 18 Aug | component |
| beam-processors | 1.35.2 | 31 Aug | component |
| rest-api | 1.220 · 1.221 · 1.222 · 1.223 | 18–27 Aug | component (4 tags) |
Deployments by environment
| Environment | S1 | S2 | S3 |
|---|
| Production | 1 | 1 | 0 |
| Preproduction | 3 | 0 | 1 |
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 | 26.8 | 43.2 | 25.5% | 9% | 176% |
| S2 | 30.1 | 56.2 | 44.5% | 37% | 256% |
| S3 | 26.3 | 61.2 | 47.5% | 20% | 278% |
| PI 10 avg | 32.7 | 38.3 | 50.1% | 42% | 167% |
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 | 9 of 10 goals hit across PI 11 (90%) | On track |
| Production release cadence | 1 platform release per active sprint | 2 production releases across S1–S3 | Behind pace |
For the conversation
Three questions the data raises. They are questions, not conclusions: the team knows things the warehouse does not.
1
The plan keeps growing and the capacity doesn't
Commitment went 43.2 → 56.2 → 61.2 points across the PI while capacity stayed near 28. Velocity followed this sprint, which is the good news. What happens to the roughly 32 committed points that didn't move? Do they carry, get re-estimated, or quietly drop?
2
Preproduction is where 3.14.0 stopped
Two release candidates went into preproduction and neither went further. What is the gate between preproduction and production for the platform, how long does it usually take, and who decides it has been cleared?
3
Pen test fixes arrived as defects
Bug work went from 1 to 8 as the pen test goal was delivered. That was planned work showing up in the defect count. Is that the right home for it, or does it make the defect trend harder to read?
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.