Aggregated sprint ADS Q3 W33 - 17-21 Aug • deduplicated roll-up across included teams
This org roll-up aggregates deduplicated frozen issue facts across 4 team snapshots. Count metrics link to snapshot-exact JQL result pages. Jira IDs in the report link to live Jira issues.
Download DOCXYellow. The sprint closed 15/62 visible items. The org roll-up absorbed noise reasonably well — 2/11 added items were closed — but predictability on committed work was only 26.4% (14/53), and bugs made up 40.0% of completed items. The main drag was execution system quality, not readiness: 19/39 carryovers had been marked Ready at planning time.
| Metric | Value | How to read it |
|---|---|---|
| Committed completion | 26.4% (14/53) | Planned items marked Done ÷ all planned committed items |
| Committed carryover | 73.6% (39/53) | Planned committed carryovers ÷ all planned committed items |
| Finish predictability | 32.5% (13/40) | Finish-intent planned items done ÷ all finish-intent planned items |
| Progress predictability | 91.7% (11/12) | Progress items that behaved as intended by carrying |
| Added-during-sprint load | 17.7% (11/62) | Added items ÷ all visible items |
| Added work closure | 2/11 | All added items marked Done |
| Reactive load (bug share) | 40.0% (6/15) | Completed bugs ÷ all completed work |
| Planning quality | 56.6% (30/53) | Committed items marked Ready ÷ all committed items |
| Workflow-truth mismatches | 0 | Items marked Done in review while workflow status remained non-final |
Across included teams, the sprint did not fail; it traded predictability for responsiveness. 2/11 added items were closed, but that responsiveness came with 40.0% bug share and diluted committed completion.
The miss pattern is concentrated: 20 partial-completion carryovers, 4 dependency-driven misses, and 15 committed items that never really started.
Most misses were not caused by poor readiness. 19 of the 39 carryovers had been marked Ready, so the stronger hypothesis is breakdown, sequencing, and capacity protection rather than simple scoping immaturity.
| Type | Planned | Added | Stretch | Unclear | Total done | Done % |
|---|---|---|---|---|---|---|
| Story | 4 | 0 | 0 | 0 | 4 | 26.7% |
| Task | 4 | 0 | 0 | 0 | 4 | 26.7% |
| Bug | 4 | 2 | 0 | 0 | 6 | 40.0% |
| Signal | Value | Why it matters |
|---|---|---|
| Committed items | 53 | Explicit promise set |
| Committed done | 14 | Closed as promised |
| Committed carry over | 39 | Unfinished promise |
| Committed items marked Ready | 30 | Planning-quality input |
| Carryovers marked Ready | 19 | Ready did not guarantee finish |
| Carryovers not started | 15 | Execution focus gap |
| Carryovers started but unfinished | 20 | Work moved, but did not close |
| Pattern | Count | What it suggests |
|---|---|---|
| Partial completion | 20 | Breakdown / sizing / stage-gating was not tight enough |
| Dependency delay | 4 | Capacity protection or dependency timing created slip |
| Not started | 15 | A committed item remained outside execution focus |
| In Progress / Code Review carryovers | 20 | Most misses were moving, but not closing |
Items marked Done in the sprint-review field while Jira workflow status was still non-final.
| Jira item | Status | Intent |
|---|---|---|
| None |
| Question | Why this matters | What evidence to ask for |
|---|---|---|
| Why did committed items carry over despite planning readiness? | This tests execution quality rather than just scope quality. | Show carryovers split by progress continuation, dependency, and not-started. |
| Are Progress items being managed intentionally? | Progress items are allowed to continue, but the continuation should be visible and controlled. | Show the original slice and the specific landing expectation for each item. |
| Is added work a healthy responsiveness level or chronic interruption? | High responsiveness can hide systemic instability and diluted predictability. | Show which added items were urgent/reactive versus discretionary scope change. |
| Can we trust Done in review when workflow is still non-final? | Workflow-truth gaps reduce trust and make completion easy to game. | Show the exact mismatches and the completion rule to enforce next sprint. |
Included teams in this org pulse: Mobile, Team 1, Team 2, University.
Usage note: start with the top-line metrics, then use the traceability links to answer these questions with issue-level evidence.
| Snapshot | Issue count | Link |
|---|---|---|
| Planning snapshot raw list | 55 | 55 issues in the planning snapshot |
| Sprint review / outcome snapshot raw list | 66 | 66 issues in the Friday review snapshot |
| Normalized sprint fact base | 62 | 62 issues used for metrics and drill-down |
Planning and outcome are separate frozen moments.
Metric tables use the normalized sprint fact base, which keeps planning-only misses and outcome-only additions visible for traceability.
| Artifact | Link |
|---|---|
| Issue audit register | Open issue-level audit CSV |
| Metric lineage | Open metric lineage CSV |
| JQL traceability register | Open JQL traceability CSV |
| Sprint metrics JSON | Open sprint metrics JSON |
These companion artifacts keep the pulse debuggable when a leader wants the exact rows behind a metric or a count.