Sprint Planning

Why two tiers?

• Stakeholders don't need to see "add migration for sharing_token field"
• Developers don't need to wade through stakeholder-facing acceptance criteria mid-implementation
• Panel Todo supports blocked_by, assignee, and isBlocked for multi-session coordination
• One Jira story often becomes 2-5 Panel Todo tasks

Workflow Steps

Step 1: GATHER CONTEXT

Understand what needs to be planned:

• What features/changes are in scope?
• What's the priority order?
• Any dependencies or blockers?

Step 2: CREATE STORIES (Ticket Tracker)

Create high-level stories in your ticket tracker:

• Clear summary with category prefix
• Acceptance criteria (testable)
• Priority and sprint assignment
• Dependencies noted

Step 3: ARCHITECTURE REVIEW (Optional)

For complex sprints, invoke arch-planner to:

• Assess blast radius of planned changes
• Identify cross-module dependencies
• Recommend story ordering
• Flag high-risk changes

Step 4: SPRINT EXECUTION BRIDGE (Panel Todo)

Bridge from ticket tracker stories to code-level tasks:

panelTodo_createSprint(name="Sprint X: {Goal}", goal="{Sprint goal}")

panelTodo_batchCreateIssues(
  sprintId="...",
  issues=[
    # From story PROJ-100 (Build tour sharing)
    { title: "Add sharing_token field to Tour model", priority: "high",
      description: "From PROJ-100. Add UUID field..." },
    { title: "Create /tours/{id}/share endpoint", priority: "high",
      description: "From PROJ-100. POST endpoint...", blocked_by: ["PT-1"] },
    { title: "Add ShareButton component", priority: "medium",
      description: "From PROJ-100. Frontend...", blocked_by: ["PT-2"] },
  ]
)

Mapping: Each story produces 1-5 Panel Todo tasks. Include the ticket key in description for traceability.

Step 5: DOCUMENT

Create sprint overview documentation:

• Sprint goal (one sentence)
• Stories grouped by category
• Execution order
• Success criteria

Panel Todo Sprint Fields

Chaining

/sprint-planning                    <- organize stories + create Panel Todo sprint
        |
/batch-dev                          <- parallel sessions claim + implement tasks
        |
/prepare-git-staging                <- validate before push

Or for single-session:

/sprint-planning -> /dev (one story at a time)

Enforcement

• NO code edits allowed (planning only)
• Design agents (arch-planner) allowed
• .md writes allowed (documentation)