Sprint Report · PI 11 · Sprint 3
Data
18 August – 1 September 2026 DES PI11S3
Both sprint goals missed, in the sprint with the best completion of the PI
1.2.0-rc.1 was tagged across all three repositories between 24 and 26 August, and the “Release 1.2.0 on pre-prod” goal was still marked missed, as was the scheduled-task asset goal for Web. The board numbers read better than that: 14 of 25 committed points completed and 19 points resolved against a capacity of 17.2. This is the first sprint of PI 11 where no goal was hit.
The sprint at a glance
Every comparison on this page is against Data'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
110%
19 of 17.2 points resolved · 90% average in PI 10
Sprint Goals Hit
0 / 2
0% this sprint · 4 of 6 across PI 11
Demand vs Capacity
215%
commitment plus unplanned work · 223% average in PI 10
Merge Requests Merged
13
19 opened · 23.6 per sprint in PI 10
Defects Resolved
4
bugs and anomalies · 4.4 per sprint in PI 10
Versions Tagged
3
in the sprint window
Sprint goals
Every goal exactly as written on the board, with the team's own assessment at sprint close.
- ✗Release 1.2.0 on pre-prod
- ✗Completed assets for Web: scheduled task and scheduled tasks completion
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 |
|---|
| data-ecosystem | 1.2.0-rc.1 | 26 Aug | release candidate |
| data-ecosystem-core | 1.2.0-rc.1 | 24 Aug | release candidate |
| data-ecosystem-infrastructure | 1.2.0-rc.1 | 25 Aug | release candidate |
Deployments by environment
Deployment tracking is not configured for Data, 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 | 16.7 | 31 | 38.7% | 49% | 277% |
| S2 | 19.5 | 13 | 30.8% | 231% | 221% |
| S3 | 17.2 | 25 | 56.0% | 48% | 215% |
| PI 10 avg | 20.5 | 20.2 | 36.6% | 126% | 223% |
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 6 goals hit across PI 11 (67%) | Below target |
| Team deliverable goals | n/a | Data's 2026 goals are project deliverables (HA architecture, migration, load test) tracked as Jira initiatives, not warehouse metrics | Not measured |
For the conversation
Three questions the data raises. They are questions, not conclusions: the team knows things the warehouse does not.
1
An RC tag is not the same as a pre-prod release
All three repositories were tagged 1.2.0-rc.1 within three days, and the pre-prod goal was still missed. What sits between the tag and pre-prod (approval, environment availability, someone's time), and is that step visible on the board?
2
Two release-shaped goals, two misses
S1 and S2 goals were phrased as technical completion (“get the technical work done and fully approved”, “start work on the CDS spike”) and both sprints hit 2 of 2. S3's goals both depended on something leaving the team. Is the difference the work, or the way the goal is written?
3
How much of the sprint is actually plannable?
Unplanned work has run at roughly half the commitment or more all PI, against a capacity of 17 points. If that is the steady state rather than the exception, is it worth planning a smaller commitment and holding the rest as reserve?
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.