Sprint Report · PI 11 · Sprint 3
Fusion
18 August – 1 September 2026 FUSION PI11S3
Every goal hit, at the lowest volume of the last nine sprints
Both sprint goals were achieved, keeping Fusion at 8 of 8 across PI 11, and no defects were resolved because none came in. Volume tells a different story: 7.5 points resolved against a capacity of 19.8, the lowest of any sprint since PI 10 opened, and 8 merge requests merged against a PI 10 average of 22. Nothing was tagged for release during the sprint.
The sprint at a glance
Every comparison on this page is against Fusion'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
38%
7.5 of 19.8 points resolved · 116% average in PI 10
Sprint Goals Hit
2 / 2
100% this sprint · 8 of 8 across PI 11
Demand vs Capacity
141%
commitment plus unplanned work · 198% average in PI 10
Merge Requests Merged
8
9 opened · 22.4 per sprint in PI 10
Defects Resolved
0
bugs and anomalies · 2 per sprint in PI 10
Versions Tagged
0
nothing tagged this sprint
Sprint goals
Every goal exactly as written on the board, with the team's own assessment at sprint close.
- ✓XCures requery ticket should be completed (dev env.)
- ✓Common PSR work - 5 SP should be completed
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.
No versions were tagged in any Fusion repository during this sprint. Both sprint goals were scoped to development completion in the dev environment, so this is consistent with the plan rather than a gap against it.
Deployments by environment
Deployment tracking is not configured for Fusion, 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 | 19.7 | 27.5 | 60.0% | 35% | 188% |
| S2 | 13 | 27 | 61.1% | 33% | 277% |
| S3 | 19.8 | 24 | 27.1% | 17% | 141% |
| PI 10 avg | 19.2 | 30.1 | 63.5% | 26% | 198% |
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 | 8 of 8 goals hit across PI 11 (100%) | On track |
| Team deliverable goals | n/a | No warehouse-measurable 2026 engineering goal is defined for Fusion | Not measured |
For the conversation
Three questions the data raises. They are questions, not conclusions: the team knows things the warehouse does not.
1
Two true things about this sprint
Goals: 8 of 8 across PI 11. Points resolved: 22.5 → 20.5 → 7.5. Both are accurate. Which one describes the sprint the team actually had, and what would have to change for them to agree?
2
Was the capacity figure right?
Capacity read 19.7, then 13, then 19.8 across the PI while merge requests went 16 → 7 → 8. If availability was lower than the capacity number said, the sprint looks worse than it was, and the fix is in how capacity is set, not in the delivery.
3
Fewer goals, bigger goals
S1 and S2 each carried three goals; S3 carried two, one of them scoped as “5 SP completed”. Is that consolidation deliberate, and does a points-shaped goal tell the team as much as an outcome-shaped one?
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.