Scrum Events
Five events, one container
All events are timeboxed and exist to enable transparency and inspection/adaptation. The Sprint (one month or less) is the container; the others occur within it.
- Sprint Planning - why (Sprint Goal), what (selected items), how (plan). Timebox: 8 hours max for a one-month Sprint.
- Daily Scrum - 15 minutes, for Developers, to inspect progress toward the Sprint Goal and adapt the plan; not a status meeting.
- Sprint Review - inspect the Increment with stakeholders and adapt the Product Backlog; a working session, not a gate or demo-only.
- Sprint Retrospective - inspect how the last Sprint went regarding individuals, interactions, processes, tools, and Definition of Done; identify improvements.
Timebox scaling
Shorter Sprints scale timeboxes down (e.g., two-week Sprint ≈ 4 hours Planning, 2 hours Review, 1.5 hours Retrospective). Questions often reward "shorter for shorter Sprints" over exact fixed numbers.
Traps
- Treating the Daily Scrum as a report to the Scrum Master or Product Owner.
- Making the Sprint Review a sign-off/acceptance gate; it is collaborative inspection, not approval.
- Using the Retrospective only for complaining without choosing improvements.
- Adding events or extending timeboxes "just this once."
- Believing the Sprint Goal must be met or the Sprint is failed; cancellation is rare and only the Product Owner may cancel.
Rule of thumb
Each event answers a question: Planning - why/what/how? Daily - are we on track to the Sprint Goal? Review - what did we build and what should change? Retrospective - how do we get better? Match the question to the event.
Worked example
Stakeholders want a formal approval meeting in addition to the Review. Correct reasoning: the Review already inspects the Increment and adapts the backlog; adding a gate undermines empiricism and self-management.