Plan, execute, review, and retrospect a complete sprint from start to finish
⏱ ~20 min · Hands-on
You'll run through an entire sprint lifecycle — creating stories, estimating them, planning a sprint, running daily standups, demoing work, and capturing improvements.
Your TaskFlow project is set up. The product owner wants users to manage basic tasks by the end of Sprint 1. You need to plan a 2-week sprint with three stories: add a task, mark a task complete, and delete a task. Let's run the full sprint ceremony cycle.
Start by defining what needs to be built. Run the command once per story, providing a feature description:
/agile-story-create Add a new task so users can track work they need to doThe AI guides you through structured story creation. Here's what the three stories look like:
📝 Story created: US-001
Title: Add a new task
As a user, I want to add a new task so that I can track work I need to do.
Acceptance Criteria:
Given I provide a valid task title and optional description
When I submit the new task
Then the task is created with status "pending"
And the task appears in my task list
And a unique ID is assigned
Given I submit without a title
When the system validates the input
Then a 400 error is returned with message "Title is required"
---
📝 Story created: US-002
Title: Mark a task as complete
As a user, I want to mark a task as complete so that I can track my progress.
Acceptance Criteria:
Given a task exists with status "pending"
When I mark it as complete
Then the status changes to "completed"
And a completedAt timestamp is recorded
Given a task is already completed
When I try to mark it complete again
Then a 409 error is returned with message "Task already completed"
---
📝 Story created: US-003
Title: Delete a task
As a user, I want to delete a task so that I can remove items I no longer need.
Acceptance Criteria:
Given a task exists
When I delete it
Then the task is removed from the database
And it no longer appears in my task list
Given I try to delete a non-existent task
When the system looks up the task
Then a 404 error is returned with message "Task not found"Every acceptance criterion uses the Given/When/Then format. This isn't just documentation — these directly become test scenarios when you use /agile-code-tdd later. Clear AC = clear tests = fewer bugs.
Estimate the effort for each story using story points:
/agile-story-estimate📊 Story Estimates:
US-001: Add a new task
Complexity: Low — standard CRUD, input validation
Uncertainty: Low — clear AC, known patterns
Estimate: 2 points
US-002: Mark a task as complete
Complexity: Medium — state transition, timestamp logic, conflict handling
Uncertainty: Low — clear AC
Estimate: 3 points
US-003: Delete a task
Complexity: Low — standard delete, existence check
Uncertainty: Low — clear AC
Estimate: 2 points
Total backlog: 7 points across 3 stories.Even though "mark complete" sounds simple, it involves a state transition (pending to completed), timestamp management, and a conflict check (already completed). The AI recognizes this added complexity and estimates accordingly.
Now pull stories into a sprint with a clear goal and capacity:
/agile-sprint-planning🏃 Sprint Planning: Sprint 1
════════════════════════════
Sprint Goal: "Users can manage basic tasks — create, complete, and delete"
Duration: 2 weeks (10 working days)
Capacity: 10 story points
Stories pulled:
┌──────────┬──────────────────────────┬────────┬──────────┐
│ ID │ Title │ Points │ Priority │
├──────────┼──────────────────────────┼────────┼──────────┤
│ US-001 │ Add a new task │ 2 │ P1 │
│ US-002 │ Mark task as complete │ 3 │ P2 │
│ US-003 │ Delete a task │ 2 │ P3 │
└──────────┴──────────────────────────┴────────┴──────────┘
Total committed: 7 / 10 points (30% buffer for unknowns)
Implementation order: US-001 → US-002 → US-003
Rationale: Build the data model first (create), then add behavior (complete), then cleanup (delete).
✅ Sprint 1 planned. Ready to implement.Only 7 of 10 points were committed. Good sprint planning leaves room for unexpected complexity, bug fixes, and code review cycles. Never commit 100% of capacity in your first sprint.
Now you implement each story. The details of building a feature are covered in Tutorial 03, but the high-level flow is:
Repeat this flow for US-001, US-002, and US-003 in order.
Each day (or work session), check in on progress:
/agile-sprint-daily📍 Daily Standup — Sprint 1, Day 4
═══════════════════════════════════
Done (since last standup):
✅ US-001: Add task — DONE (merged to main)
✅ US-002: Mark complete — PR open, review in progress
Doing (today):
🔄 US-002: Address review feedback (rename parameter, add JSDoc)
📋 US-003: Start planning phase
Blockers:
🚫 None
Sprint progress: 5/7 points done (71%)
Sprint health: 🟢 On trackThe standup command generates a snapshot of where things stand. Use it to catch blockers early and adjust priorities. If you see 🔴 "at risk," consider dropping a lower-priority story.
At any point during the sprint, you can get a detailed progress overview — burndown, velocity trend, and risk indicators:
/agile-sprint-status📊 Sprint Status — Sprint 1
═════════════════════════════
Progress: 5/7 points done (71%)
Days left: 6 of 10
Burndown: 🟢 On track (ideal: 4.2 pts done, actual: 5 pts)
Story breakdown:
✅ US-001: Add a new task (2 pts) — DONE
🔄 US-002: Mark task as complete (3 pts) — IN REVIEW
📋 US-003: Delete a task (2 pts) — TODO
Risk: None detected
Forecast: Sprint goal likely to be met by Day 8/agile-sprint-daily captures what you did and plan to do (standup format). /agile-sprint-status gives a data-driven progress view — burndown, forecasts, and risk indicators. Use daily for communication, status for decision-making.
At the end of the sprint, demo what was built:
/agile-sprint-review🎬 Sprint Review — Sprint 1
════════════════════════════
Sprint Goal: "Users can manage basic tasks"
Result: ✅ GOAL MET
Stories Delivered:
✅ US-001: Add a new task (2 pts) — ACCEPTED by @po
✅ US-002: Mark task as complete (3 pts) — ACCEPTED by @po
✅ US-003: Delete a task (2 pts) — ACCEPTED by @po
Velocity: 7 points
Demo:
1. POST /api/v1/tasks — created task "Buy groceries" → 201, ID assigned
2. PATCH /api/v1/tasks/1/complete — status changed to "completed" → 200
3. DELETE /api/v1/tasks/1 — task removed → 204
4. GET /api/v1/tasks — empty list confirmed → 200
Stakeholder feedback:
@po: "Clean implementation. Next sprint: add due dates and filtering."
✅ All 3 stories accepted. Sprint 1 complete.Capture what went well, what to improve, and specific action items:
/agile-sprint-retro🔄 Sprint Retrospective — Sprint 1
════════════════════════════════════
What went well:
👍 TDD caught 3 edge cases before code review (null title, empty string, whitespace-only)
👍 Code review feedback was specific and actionable
👍 30% buffer was right — actual velocity matched estimate
What to improve:
⚠️ Acceptance criteria for US-002 didn't specify what happens to completedAt on re-complete
⚠️ Integration tests took longer to set up than expected (DB seeding)
Action items:
📌 ACTION: Review AC template — add explicit error/edge case scenarios before estimation
📌 ACTION: Create shared test fixtures for database seeding
📌 ACTION: Add "negative scenarios" as a checklist item in story creation
Owner: Team | Due: Before Sprint 2 planningThe retro isn't just reflection — it produces concrete action items that feed into the next sprint. The action "review AC template" will prevent the ambiguity that caused confusion in US-002.
Persist what you learned so it carries forward to every future sprint:
/agile-memory-learn🧠 Learning captured:
Sprint 1 Learnings:
• Detailed acceptance criteria (including negative scenarios) saves debugging time during implementation
• 30% sprint buffer is appropriate for a new project with unknown velocity
• TDD with Given/When/Then AC produces comprehensive test coverage naturally
• Database test fixtures should be set up once as shared infrastructure, not per-story
Saved to: .memory/episodic/decisions.md (appended)
Tagged: sprint-1, process, estimationWithout this step, every sprint starts from zero. With it, the AI remembers that your team estimates accurately at 70% capacity, that you prefer detailed AC, and that test fixtures exist. Each sprint gets smarter.
After the sprint review, what ceremony captures improvements for the next sprint?