Agile at Prolaio · PI 11 Snapshot

Goal achievement rose from 76% in each of PI 9 and PI 10 to 83.6% in PI 11, while the share of selected backlog completed stayed flat at around 45%. Teams increasingly keep the promise they make at outcome level even though they finish less than half of the items they select.

Some goals describe an outcome a stakeholder would recognise; others restate a ticket or a points total, which is easy to mark as met but says little about value. Six of the twelve goals missed in PI 11 are the same two items carried from sprint to sprint, each missed three times. One team met every goal while its output fell; another missed repeatedly. Goal results are also edited after a sprint closes, so the same sprint can read differently weeks later.

Demand, meaning the work planned at sprint start plus the work added during the sprint, has been 211%, 206%, 200% and 196% of capacity across PI 8 to PI 11. It is the most stable number in our data, and changes to how teams plan have not moved it. Delivery holds at roughly 95% of capacity regardless. A plan built on this demand cannot hold for a whole PI.

The two teams planning at 227% of capacity account for 10 of the 12 goals missed in PI 11. The team that brought demand down from 154% to 116% went from 40% to 100% of goals met. The pattern is not clean: another team met 19 of 19 goals at 197% demand, which raises the question of how ambitious its goals were.

To push for better planning and predictable delivery, teams were given two sprint targets: complete at least 80% of what they committed at sprint start, and keep work added mid-sprint to no more than 20% of that commitment. The intent was sound. In practice both ratios divide by the commitment the team itself sets, so a bigger plan makes creep look smaller and completion look worse, and the two targets pull in opposite directions. Teams responded to the creep target by committing more.

Across 93 sprints, none met both targets. The amount of work added mid-sprint is unrelated to the size of the plan, so a lower creep ratio reflected a larger plan, not fewer interruptions. The predictability problem itself is real: even sprints planned close to capacity completed only about half of their commitment. Both ratios are now reported for diagnosis only, and sprint goals carry the commitment.

Only 41% of sprints land within the middle 50% of their own team's recent sprints, and sprint velocity differs from the team's own recent median by 35% on average. At PI level the picture is steady: teams deliver 92 to 99% of capacity every PI.

PI Planning asks for epics and estimated stories, including where the solution is unknown, and at org level it tends to go into team-level detail when its purpose is agreeing objectives and surfacing dependencies. Detailed estimates for unknown work produce false precision that teams are then measured against. Teams also struggle with spikes: it is unclear whether a spike should carry the estimate for the follow-up work it uncovers.

The PI 11 IP sprint carried 151.8 points of commitment and 11 sprint goals, with the highest demand of the PI (222% of capacity) and the lowest goal result (7 of 11). With demand at twice capacity, change during the PI is certain, and with the IP sprint fully planned there is no slack left to absorb it. Teams feel frustrated when the plan changes; that may come from how full and how detailed the plan is rather than from change itself.

Alongside agile metrics we track DORA metrics, to see whether what teams complete actually reaches users. PI 11 produced 113 version tags (64 of them alpha, beta or release-candidate builds) and 6 production deployments. Nothing reached production in sprints 3, 4 and 5; two releases were promoted in the IP sprint. Median lead time from commit to production was 24 to 25 days for Cloud and 53 days for Web, against a 7-day target. The bottleneck appears to be promotion to production rather than build or test. Only Cloud and Web can be measured today: Mobile ships through app-store channels, and Data and Fusion have no production environment mapped in our metrics.

There is also no established sprint review practice. Without a regular moment where stakeholders see working software, "done" tends to mean merged or tagged. One idea under discussion: each team reviews its own work, records the strongest demos and shares them more widely, live or asynchronously, to drive real business value, iteration and a definition of done that means "ready to use".