Agile Ceremonies
This document defines the sprint cadence. Teams may adapt the exact format, but the core outputs should stay consistent.
Suggested Cadence
| Ceremony |
Frequency |
Duration |
Participants |
Primary Output |
| Sprint Planning |
Every sprint |
1.5 to 2 hours |
Core team, product owner |
Sprint goal and committed work |
| Daily Scrum |
Daily |
10 min. OR Async in Shared Channel |
Core team |
Shared plan and blocker visibility |
| Backlog Refinement |
Weekly |
30 to 60 minutes |
Product owner, subject matter experts or engineers as required |
Ready backlog |
| Sprint Review |
End of sprint |
1 to 2 hours |
Core team, product owner, stakeholders |
Feedback and accepted work |
| Retrospective |
End of sprint |
30 to 60 minutes |
Core team |
One or two improvements |
Two-week sprints are a good default, but teams may adapt based on project size and learning speed.
Sprint Planning
Purpose:
- set a clear sprint goal
- choose a realistic amount of work
- confirm a shared understanding of scope and acceptance criteria
Inputs:
- current PRD or delivery plan
- prioritized backlog
- team capacity
- known risks and dependencies
Outputs:
- sprint goal
- committed work
- initial task breakdown as needed
Daily Scrum
Purpose:
- synchronize the team
- surface blockers quickly
- adjust the plan before drift grows
This can be synchronous or async. For distributed teams, async is often better.
Suggested async format:
- Yesterday: what changed
- Today: next planned work
- Blockers: what needs help
The Scrum Lead should review blockers daily and actively remove them.
Backlog Refinement
Purpose:
- keep the top of the backlog ready
- clarify scope before planning
- split large work into smaller slices
Use refinement to:
- translate feedback into backlog items
- add or improve acceptance criteria
- identify dependencies and technical constraints
- do first-pass estimation if useful
Sprint Review
Purpose:
- demonstrate completed increments
- gather stakeholder feedback
- decide what changes next
Outputs:
- accepted or rejected work
- feedback captured as new or updated tickets
- follow-up actions with owners
Retrospective
Purpose:
- inspect how the sprint worked
- identify one or two changes to improve the next sprint
Keep retrospectives short, honest, and blameless. If every retro produces a long list, the team will ignore it.
Estimation And Capacity
- use relative estimation when it helps compare effort
- re-estimate only when scope materially changes
- subtract meetings, support work, holidays, and buffer before committing
- track carryover and use it to improve planning, not to blame
Practical Rule
Each ceremony should produce a decision or artifact the team actually uses. If a meeting exists only because the calendar says it should, simplify it or remove it.