Lesson 05
From planning to retrospective — every event in a sprint, step by step.
A Sprint is a time-boxed iteration — typically 1 to 2 weeks — during which the team builds a potentially shippable product increment. Sprints are the heartbeat of Scrum. They create a predictable cadence for planning, building, reviewing, and improving.
A sprint never extends. If the team cannot finish all planned work, they carry unfinished stories back to the backlog. If they finish early, they pull the next highest-priority item. The fixed timebox creates discipline and predictability.
Sprint Planning kicks off every sprint. The entire Scrum Team collaborates to define what can be delivered and how the work will be achieved. It is timeboxed to 2-4 hours for a 2-week sprint.
The Product Owner proposes an objective for the sprint based on the backlog priorities. The team discusses and commits to a goal that provides coherence and focus.
# Example Sprint Goal
"Users can sign up and authenticate using Google OAuth,
enabling passwordless onboarding for the first time."The team reviews their capacity (available hours, accounting for PTO, meetings, etc.) and their historical velocity (average story points completed per sprint). They then select stories from the top of the backlog that fit within capacity.
# Capacity Calculation
Team members: 3 developers
Sprint length: 2 weeks (10 working days)
Availability: Dev A: 100%, Dev B: 80%, Dev C: 100%
Focus factor: 70% (meetings, interruptions, etc.)
Capacity = (1.0 + 0.8 + 1.0) × 10 × 0.70 = 19.6 person-days
Historical velocity: ~21 story points per sprint
→ Commit to 18-21 points of workThe Development Team breaks selected stories into technical tasks. Each task should be small enough to complete in a day or less. This creates a plan — the Sprint Backlog — that the team owns and manages.
The Daily Standup (or Daily Scrum) is a 15-minute time-boxed event for the Development Team to synchronize work and plan the next 24 hours. It happens every day at the same time and place.
| Question | Purpose | Example Answer |
|---|---|---|
| What did I do yesterday? | Share progress with the team | "Completed the OAuth callback handler and wrote unit tests" |
| What will I do today? | Commit to today's work | "Integrate the account creation flow and start on error handling" |
| Are there any blockers? | Surface impediments early | "I need the Google OAuth credentials from DevOps before I can test" |
Status report to the manager — The standup is for the team, not for a manager. Everyone talks to each other, not to one person.
Problem-solving in the standup — If a discussion goes beyond 30 seconds, take it offline: "Let's park that. Dev A and Dev B, sync up after standup."
Going over 15 minutes — Keep it crisp. Stand up (literally) to keep it short.
During the sprint, the team executes the plan. In our Agile Workflow, the development loop follows a structured pattern for each story.
# For each story in the sprint:
1. Pick the top story from "To Do" → move to "In Progress"
2. Run /agile-code-branch to create a feature branch (e.g. feature/42-google-oauth)
3. Write failing tests first (TDD - Red phase)
4. Implement until tests pass (Green phase)
5. Refactor for clarity and cleanliness
6. Run /agile-code-ci to verify build, tests, lint all pass
7. Run /agile-code-commit to create conventional commits linked to the story
8. Run /agile-code-pr to open a pull request for code review
9. Run /agile-code-pr-review — @lead reviews the PR
10. Address review feedback
11. Run /agile-code-merge to merge to develop and clean up the branch
12. Run /agile-story-dod to verify the Definition of Done
13. Move story to "Done" on the boardThe Sprint Review is held at the end of the sprint. The team demonstrates working software to stakeholders and collects feedback. This is not a status meeting — it is a live demo of the increment.
The Sprint Review is about inspection and adaptation of the product. Show real, working functionality. If a story is 90% done, it is not demonstrated — only "Done" work is shown. This enforces the Definition of Done and builds trust with stakeholders.
The Retrospective is the team's opportunity to inspect itself — its process, interactions, tools, and environment — and create a plan for improvements. It is the most important ceremony for continuous improvement.
| What Went Well | What To Improve | Action Items |
|---|---|---|
| TDD caught a critical bug early | PR reviews took too long (2+ days) | Set a 24-hour SLA for first review |
| Sprint goal was clear and focused | Sprint started before designs were ready | Add "UX approved" to Definition of Ready |
| Pair programming on complex stories worked great | Standup sometimes ran over 15 minutes | Use a timer; defer discussions to follow-ups |
The retrospective feeds directly into /agile-memory-learn. Learnings captured during the sprint — plus insights from the retro — are recorded in the memory system. This means the AI remembers what worked and what didn't across sprints, creating genuine continuous improvement.
The burndown chart shows remaining work (in story points) over the sprint duration. The ideal line goes from total points to zero. The actual line shows real progress. Gaps between ideal and actual surface problems early. Use /agile-sprint-status to get a data-driven view of sprint progress including burndown, velocity forecasts, and risk indicators.
| Day | Ideal (pts remaining) | Actual (pts remaining) | Status |
|---|---|---|---|
| 1 | 21 | 21 | Starting |
| 2 | 18.9 | 18 | On track |
| 3 | 16.8 | 15 | On track |
| 4 | 14.7 | 12 | Ahead |
| 5 | 12.6 | 12 | On track |
| 6 | 10.5 | 9 | Slightly behind |
| 7 | 8.4 | 6 | Recovering |
| 8 | 6.3 | 6 | On track |
| 9 | 4.2 | 3 | On track |
| 10 | 0 | 0 | Complete |
Velocity is the number of story points the team completes per sprint, averaged over time. It is the primary tool for capacity planning and forecasting.
# Velocity over 5 sprints
Sprint 1: 18 points completed
Sprint 2: 22 points completed
Sprint 3: 20 points completed
Sprint 4: 19 points completed
Sprint 5: 21 points completed
Average velocity: 20 points/sprint
# Forecasting
Remaining backlog: 120 points
Estimated sprints remaining: 120 / 20 = 6 sprints
Estimated completion: ~12 weeks (6 × 2-week sprints)Velocity is a planning tool, not a measure of team productivity. Comparing velocity between teams is meaningless because each team estimates differently. Using velocity as a performance target leads to point inflation and destroys its usefulness for planning.
When does the Scrum Team demonstrate working software to stakeholders?