# Epic 17: Sprint Planning Overhaul -- Adversarial Review

**Review Date:** 2026-03-28
**Scope:** Story 17.1 (Sprint Entity Model)
**Verdict:** Multiple specification conflicts and gaps -- needs corrections before dev

---

## Findings

1. **Schema mismatch between AC #1 and Task 2.5: `created_date` and `last_modified` are phantom fields.** AC #1 specifies exactly seven fields in the YAML schema: `id`, `name`, `status`, `capacity`, `start`, `end`, `items`. Task 2.5 adds two more fields (`created_date` and `last_modified`) that appear nowhere in the acceptance criteria. Task 6.2 then says "Verify new schema fields match AC #1 exactly" -- which they cannot, because Task 2.5's template has nine fields. A developer literally cannot satisfy both Task 2.5 and Task 6.2 simultaneously. Either the AC needs updating or the task needs to drop the extra fields.

2. **The story ignores the SKILL.md file entirely.** Epic 15 already converted `add-sprint` into a skill package. The file `lib/bmad-extension/skills/add-sprint/SKILL.md` exists and contains an identical copy of the workflow. The story's "Files to modify" list mentions only `lib/bmad-extension/workflows/add-sprint/workflow.md`. The `module-help.csv` entry already points to `skill:add-sprint`, which resolves to the SKILL.md, not the workflow.md. If the developer only modifies `workflow.md`, the actual invoked skill will remain unchanged and still emit the old format. This is a **showstopper omission**. The `bmad-skill-manifest.yaml` file may also need updating.

3. **No date validation specified.** Task 2.3 says dates must be ISO format `YYYY-MM-DD`, but there is no acceptance criterion, validation step, or error-handling behavior defined for invalid dates. What happens if the user enters `2026-13-45`, `next Tuesday`, or an empty string? The old workflow allowed freeform or empty values. The new schema implies strict ISO dates, but the story specifies no validation logic, no error message, and no retry loop. Compare to the capacity field (Task 2.2), which has explicit validation with an error message and a `goto` loop. Dates get nothing.

4. **Start and end dates: required or optional?** The old workflow explicitly made `start_context` and `end_context` optional ("press Enter to skip"). The new schema shows `start` and `end` as always populated. No AC or task states whether dates are required or optional. If optional, what value goes in the YAML -- empty string, `null`, omitted key? If required, the story needs to say so explicitly. Downstream story 17.8 (Sprint Status Display) will need to render these fields, so the contract matters.

5. **AC #2 is untestable within this story's scope.** AC #2 says "`items` contains an ordered list of story/bug IDs" and "the count of items never exceeds `capacity`." But the Critical Guardrails state "`items` array MUST be initialized as empty `[]` -- never pre-populated during sprint creation," and the story explicitly forbids touching `add-to-sprint` or `modify-sprint` (the only workflows that would populate `items`). Within this story, `items` will always be `[]`, and the capacity constraint can never be exercised. This AC is testing behavior that is physically impossible to trigger until Story 17.4. It should be moved to 17.4 or clearly marked as a contract specification, not an acceptance criterion for this story.

6. **AC #3 is also largely untestable within this story's scope.** AC #3 describes the transition from `planning` to `active`, but Task 3.4 says "activation is a separate action (via modify-sprint or a future activate-sprint step)" and the guardrails say "Do NOT rework modify-sprint." There is no mechanism in this story's add-sprint workflow to set a sprint to `active`, so the single-active-sprint validation (Task 3.1-3.3) cannot be triggered by anything this story delivers. The validation code would be dead code with no way to invoke it.

7. **The `name` field has no uniqueness constraint or validation.** Two sprints can have different IDs but identical names. The ID has overwrite protection (Task 2.6), but the name is free text with a default template that could easily collide. If 17.8 (Sprint Status Display) shows sprints by name, this will cause confusion. No AC addresses name uniqueness or name format validation.

8. **FR132 specifies "start/end context" but the story silently narrows to strict ISO dates.** The PRD requirement FR132 reads: "each sprint has an iteration identifier, capacity, assigned item list, start/end context, and status." The word "context" implies the old freeform model. This story silently narrows the semantics from freeform context to strict ISO dates without documenting this as a deliberate deviation from FR132 or proposing a PRD amendment.

9. **Sprint status transition rules are incomplete.** AC #3 only covers `planning -> active`. The Dev Notes say the state machine is `planning -> active -> closed`. But the story never explicitly forbids: `closed -> active` (reopening), `closed -> planning`, `active -> planning` (deactivation without closing), or creating a sprint directly in `active` or `closed` status. The guardrails document update (Task 5.3) should contain the full transition matrix, but the story only says "Add Sprint Status Transitions section" -- that is a one-line description, not a specification.

10. **The `module-help.csv` output-location column is stale.** The current entry's output-location says `_bmad-output/implementation-artifacts` -- but sprint files now go to `_bmad-output/implementation-artifacts/sprints/`. Task 4.2 says "Update description if changed" but does not identify that the output-location is also wrong. The description references "optional start/end context" which no longer applies either.

11. **No guidance on sprint ID numbering conflicts or sequencing.** The ID format is `sprint-{number}`, but nothing prevents creating `sprint-5` when only `sprint-1` exists, or creating `sprint-1` after `sprint-3`. There is no auto-increment, no next-available-number suggestion, and no validation that numbers are sequential. Downstream stories that glob and sort by ID will behave unpredictably with non-sequential numbering.

12. **The guardrails document name is misleading after this update.** The file is called `epic-11-12-shared-guardrails.md`, but after Task 5 it will contain Epic 17 content (Sprint Status Transitions, new paths, new globs). The filename no longer reflects its scope. No renaming is proposed.

13. **Interim breakage of existing workflows has no mitigation.** The story states that after 17.1, the existing `add-to-sprint`, `modify-sprint`, and `sprint-status-view` workflows will be **broken** because they still reference `sprint-plan-*.yaml` paths. The story calls this "expected and acceptable." But there is no feature flag, no deprecation warning, no stub that returns a useful error message, and no documented workaround. A Scrum Master running `/add-to-sprint` after 17.1 lands will get a silent failure or cryptic "no sprint plans found" error with no explanation.

14. **The `items` array example in AC #2 uses inconsistent ID formats without defining the contract.** The example shows `["5-5-explicit-parameter-passing", "5-6-fix-space-in-path-bug", "BUG-path-spaces"]`. Story IDs use `{epic}-{story}-{slug}` format but bug IDs use `BUG-{slug}`. This is the only place that defines the item ID format, and it is buried in an example rather than stated as a rule. Story 17.4 will need to write to this array and must know the exact format. The contract should be explicit.
