Sprint Execution

Purpose: Run sprint execution (not planning) for an existing sprint. You invoke this skill and point to a sprint plan folder; the delivery-orchestrator runs the sequence, enforces governance, and produces the full Sprint Package including UAT, Sprint Review, Audit, and release deliverables.

Planning vs execution: Planning is done by sprint-planning-facilitator (creates/updates sprint-plan.md, scope.md, tasks-by-agent.md, etc.). This skill executes that plan: who does what in order, what cannot be skipped, when escalation happens, and what artifacts are mandatory.

1. How to Invoke

User says (examples):

"Run sprint execution for docs/project/sprints/Sprint-01"
"Execute the sprint in docs/project/sprints/Sprint-02"
"Use sprint-execution skill on Sprint-03"

Input: Path to the sprint folder (e.g. docs/project/sprints/Sprint-01).

Process:

Resolve the sprint folder; confirm it contains at least sprint-plan.md, scope.md, tasks-by-agent.md, deliverables.md, references.md (from planning).
Invoke delivery-orchestrator (or act as orchestrator) and run the Execution Sequence (§2).
Enforce Governance Rules (§3); block any violation.
Produce Mandatory Sprint Package (§4) in the same sprint folder.
Ensure End-of-Sprint flow: UAT checklist, Sprint Review, Audit, and Release readiness (§5).

2. Execution Sequence (Strict Order)

Follow delivery-orchestrator. Delegate to agents in this order; collect outputs into the sprint folder.

| Step | Agent(s) | Output | |------|----------|--------| | 1 | pm | Sprint goal confirmed; scope and timeline for execution | | 2 | po | Scope validated against roadmap; backlog items confirmed | | 3 | business | Refined stories; BRD/epic traceability | | 4 | architect | Validation against approved architecture; no redesign without approval | | 5 | design-authority | Design scope and component specs (if UI in scope) | | 6 | qa-lead | Test strategy and test cases first (TDD); TC-ids, traceability | | 7 | backend-squad, frontend-squad, dev-mid, dev-junior | Unit test matrix from QA cases; then implementation plan and tasks | | 8 | devops | CI/CD impact; deployment plan; branch/tag strategy | | 9 | development-sm | Definition of Done validated; mandatory artifacts check | | 10 | delivery-orchestrator | Sprint Package compiled; UAT, Review, Audit, Release readiness |

TDD enforcement: Step 6 (QA) must complete before Step 7 (Dev). Devs produce unit test matrix from QA test cases, then implementation plan.

3. Governance Rules (No Exceptions)

No dev output without QA test strategy first. QA defines test cases; dev converts to unit tests, then implements.
No architecture redesign unless Architect + Design Authority approve.
No DB change without migration plan.
No deployment without DevOps approval.
No story complete without QA sign-off.

Escalation: Dev→Architect; Architect→Design Authority; Business impact→PO+Business. Document in risk-log.md or escalation log.

4. Mandatory Sprint Package (Sprint Folder Contents)

By end of execution, the sprint folder must contain:

| Artifact | File | Purpose | |----------|------|---------| | Sprint goal | sprint-plan.md | Already from planning; confirm/update if needed | | Refined user stories | scope.md | Epics, US-XXX, TS-XXX, dependencies | | Technical breakdown | tasks-by-agent.md, deliverables.md | Per-agent tasks; code/tests/docs to produce | | Test matrix | test-matrix.md | Test cases, TC-ids, traceability to US/TS | | CI/CD impact | cicd-impact.md | Pipeline changes, branch/tag, gates | | Deployment plan | deployment-plan.md | Steps, environment, rollback | | Risk log | risk-log.md | Risks, blockers, mitigations | | Carryover items | carryover.md | Incomplete or deferred items | | UAT checklist | uat-checklist.md | Scenarios for stakeholder manual testing as regular user | | Sprint review | sprint-review.md | What was delivered; demo; stakeholder feedback | | Audit | audit.md | Process compliance; traceability; release readiness | | Release | docs/project/releases.md | Per release-playbook: tag, log entry (when release is cut) |

Create any missing files from the template in docs/project/sprints/_template/. No freestyle responses; all structured.

5. End-of-Sprint: UAT → Sprint Review → Audit → Release

5.1 UAT (Stakeholder)

Owner: Main stakeholder (you) does manual testing as a regular user.
Input: uat-checklist.md with scenarios derived from user stories and acceptance criteria.
Rule: Release should not be signed off until UAT is done (or explicitly deferred by PM). QA Lead and PM prepare the checklist; stakeholder executes and signs off.

5.2 Sprint Review

Artifact: sprint-review.md in the sprint folder.
Content: What was delivered; demo notes; stakeholder feedback; any “done” vs “not done” list.
Owner: SM + PM.

5.3 Audit

Artifact: audit.md in the sprint folder.
Content: Compliance with process (traceability, DoD, governance); release readiness; link to release log when released.
Owner: Orchestrator / SM.

5.4 Release (Per Release Playbook)

Process: docs/development/release-playbook.md
Pre-release gate: PM, SM, QA Lead, Dev-Senior agree.
Steps: Freeze, checklist, version, tag on main, record in docs/project/releases.md, unfreeze.
Deliverable: Release tag (e.g. v1.1.0) and one row in the release log.

6. Responsibility Boundaries

Use docs/development/responsibility-boundaries.md. Orchestrator must prevent agents from overstepping (e.g. Architect does not implement; Dev does not change architecture without approval).

7. Invocation Summary

User: "Run sprint execution for docs/project/sprints/Sprint-01"
You: Load sprint folder; run delivery-orchestrator sequence (Steps 1–10); enforce governance; create/update test-matrix.md, cicd-impact.md, deployment-plan.md, risk-log.md, carryover.md, uat-checklist.md, sprint-review.md, audit.md; ensure UAT, Sprint Review, Audit, and Release deliverables are ready.
Output: Sprint folder contains full Sprint Package; stakeholder has uat-checklist.md for manual testing; sprint-review.md and audit.md ready; release path documented per release-playbook.