Agile retrospectiveprinciples, formats, and examples
Understand the principles behind agile retrospectives and adapt the practice across Scrum, Kanban, product, and project teams.
An agile retrospective is a recurring inspect-and-adapt conversation about how a team works. The team uses recent evidence to protect strengths, expose friction, and test a small improvement.
Retrospectives are strongly associated with Scrum, but the underlying feedback loop applies to Kanban, product, design, operations, and project teams. The cadence and prompts can change while the principle stays the same.
A new team may need clarity while an established team needs a harder systems question. Use the stages of team development guide to match the retrospective’s focus to the behavior the team is showing now.
The principles behind an agile retro
- Inspect real experience. Discuss observed events rather than abstract process theory.
- Include the people doing the work. Improvement is not a private management backlog.
- Adapt in small steps. Prefer a testable experiment to a sweeping process rewrite.
- Review the result. The next retrospective starts with evidence from the previous action.
Agile retrospective across methods
Scrum
Run the retrospective at the end of every sprint. Connect insights to the completed sprint while keeping the product-focused sprint review separate.
Kanban and flow-based work
Use a regular cadence or a meaningful delivery event. Include flow evidence such as blocked time, aging work, handoffs, and unplanned demand.
Product and cross-functional teams
Include discovery, design, engineering, launch, and support signals. Choose participants who shared the system being reviewed.
The product team retrospective guide shows how to connect customer evidence, decisions, handoffs, delivery, and adoption without reducing the meeting to output volume.
Example agile retrospective
A team notices that urgent work repeatedly interrupts planned delivery. Cards show three sources: production incidents, sales requests, and late compliance reviews. Instead of promising to “focus more,” the team tests an explicit expedite policy with one owner and reviews unplanned work after two weeks.
Formats for different conversations
Use Classic Sprint for a balanced review, Starfish for nuanced process tuning, DAKI for operating-model changes, and ROBIN for complex strategic work.
How to keep the practice agile
- Review the last experiment.
- Collect observations from the recent period.
- Prioritize one pattern with meaningful impact.
- Choose a reversible change within the team's influence.
- Define when and how the result will be reviewed.