Sprint Report · PI 11 · Sprint 3
Web
19 August – 2 September 2026 PW PI11S3
The plan matched the capacity, and the sprint followed it
30.5 points committed against a capacity of 31.8, and 24.5 of them completed. That is the closest alignment of plan, capacity and outcome in the last nine sprints. The single sprint goal was hit and only one defect came through. Fourteen staging deployments went out and none was promoted to production.
The sprint at a glance
Every comparison on this page is against Web'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
96%
30.5 of 31.8 points resolved · 77% average in PI 10
Sprint Goals Hit
1 / 1
100% this sprint · 4 of 4 across PI 11
Demand vs Capacity
127%
commitment plus unplanned work · 154% average in PI 10
Merge Requests Merged
19
13 opened · 19.8 per sprint in PI 10
Defects Resolved
1
bugs and anomalies · 1.2 per sprint in PI 10
Deployments
0 prod
14 to staging · 2 production across S1–S3
Sprint goals
Every goal exactly as written on the board, with the team's own assessment at sprint close.
- ✓Wrap-up participant tab and roll out on pre-production server
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 |
|---|
| prolaio-web | v1.8.3_carelab | 19 Aug | tagged on the sprint's opening day |
Deployments by environment
| Environment | S1 | S2 | S3 |
|---|
| Production | 0 | 2 | 0 |
| Staging | 6 | 3 | 14 |
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 | 22.3 | 18 | 55.6% | 22% | 99% |
| S2 | 31.1 | 10 | 70.0% | 240% | 109% |
| S3 | 31.8 | 30.5 | 80.3% | 33% | 127% |
| PI 10 avg | 29.3 | 20.3 | 45.3% | 122% | 154% |
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 | 4 of 4 goals hit across PI 11 (100%) | On track |
| Committed work completed every sprint | No sprint with zero committed points done | 10, 7 and 24.5 points completed across S1–S3 | On track |
For the conversation
Three questions the data raises. They are questions, not conclusions: the team knows things the warehouse does not.
1
What changed in planning?
Commitment went 18 → 10 → 30.5 against a capacity that held near 30. S3 is the first sprint in nine where the plan and the capacity agreed, and the outcome followed. Worth naming what was done differently, so it can be repeated.
2
Fourteen staging deployments, none promoted
The pipeline to staging is clearly working. What decides promotion to production, is that decision Web's to make, and is anything waiting on it right now?
3
One goal, thirty points
The last two sprints each carried a single sprint goal. At roughly 30 points of capacity, does one goal give the team enough to steer by mid-sprint when something unplanned arrives?
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.