Planned sprint ADS Q2 W19 - 11-15 May • planning snapshot + end-of-sprint outcome snapshot
This version uses the planning snapshot as the promise set and the outcome snapshot as the result set. Count metrics link to snapshot-exact JQL result pages. Jira IDs in the report link to live Jira issues.
Download DOCXYellow. The sprint closed 1/56 visible items. The team absorbed noise well — 0/42 added items were closed — but predictability on committed work was only 4.0% (1/25), and bugs made up 0.0% of completed items. The main drag was execution system quality, not readiness: 13/24 carryovers had been marked Ready at planning time.
| Metric | Value | How to read it |
|---|---|---|
| Committed completion | 4.0% (1/25) | Planned items marked Done ÷ all planned committed items |
| Committed carryover | 96.0% (24/25) | Planned committed carryovers ÷ all planned committed items |
| Finish predictability | 0.0% (0/19) | Finish-intent planned items done ÷ all finish-intent planned items |
| Progress predictability | 83.3% (5/6) | Progress items that behaved as intended by carrying |
| Added-during-sprint load | 75.0% (42/56) | Added items ÷ all visible items |
| Added work closure | 0/42 | All added items marked Done |
| Reactive load (bug share) | 0.0% (0/1) | Completed bugs ÷ all completed work |
| Planning quality | 52.0% (13/25) | Committed items marked Ready ÷ all committed items |
| Workflow-truth mismatches | 0 | Items marked Done in review while workflow status remained non-final |
The sprint did not fail; it traded predictability for responsiveness. 0/42 added items were closed, but that responsiveness came with 0.0% bug share and diluted committed completion.
The miss pattern is concentrated: 0 partial-completion carryovers, 0 dependency-driven misses, and 0 committed items that never really started.
Most misses were not caused by poor readiness. 13 of the 24 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 | 0 | 0 | 0 | 0 | 0 | 0.0% |
| Task | 0 | 0 | 0 | 0 | 0 | 0.0% |
| Bug | 0 | 0 | 0 | 0 | 0 | 0.0% |
| Signal | Value | Why it matters |
|---|---|---|
| Committed items | 25 | Explicit promise set |
| Committed done | 1 | Closed as promised |
| Committed carry over | 24 | Unfinished promise |
| Committed items marked Ready | 13 | Planning-quality input |
| Carryovers marked Ready | 13 | Ready did not guarantee finish |
| Carryovers not started | 0 | Execution focus gap |
| Carryovers started but unfinished | 5 | Work moved, but did not close |
| Pattern | Count | What it suggests |
|---|---|---|
| Partial completion | 0 | Breakdown / sizing / stage-gating was not tight enough |
| Dependency delay | 0 | Capacity protection or dependency timing created slip |
| Not started | 0 | A committed item remained outside execution focus |
| In Progress / Code Review carryovers | 5 | 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. |
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 | 24 | 24 issues in the planning snapshot |
| Sprint review / outcome snapshot raw list | 60 | 60 issues in the Friday review snapshot |
| Normalized sprint fact base | 56 | 56 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.