Agile retrospectiveprinciples, formats, and examples
Adapt agile retrospectives for Scrum, Kanban, product, and projects.
An agile retrospective is a recurring inspect-and-adapt conversation about how a team works. The team uses recent evidence to protect strengths, find friction, and test a small improvement.
Scrum made retrospectives familiar to many teams. The same feedback loop works for Kanban, product, design, operations, and project work, with cadence and prompts chosen for each team's situation.
A new team may need clarity. An established group may get further with a difficult question about its system. 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. Start with observed events and leave abstract process theory for another conversation.
- Include the people doing the work. Put improvement in the hands of the team that lives with the process and sees its effects during daily work.
- Adapt in small steps. Test one small, reversible change and track the result before another change enters the team's system.
- Review the result. Open the next retrospective with evidence from the previous action.
Agile retrospective across methods
Scrum
Run the retrospective at the end of every Sprint. Connect its observations to the completed Sprint, then keep the product-focused Sprint Review separate because that event examines the product with stakeholders.
Kanban and flow-based work
Choose a regular cadence or a meaningful delivery event. Bring blocked time, aging work, handoffs, and unplanned demand.
Product and cross-functional teams
Bring discovery, design, engineering, launch, and support signals into the discussion so the group can see the whole path from decision to adoption. Invite the people who shared the system under review.
The product team retrospective guide connects customer evidence with decisions, handoffs, delivery, and adoption. Output volume stays in context alongside those signals.
Example agile retrospective
A team notices that urgent work repeatedly interrupts planned delivery. Its retrospective cards point to three recurring sources of interruption during planned work for the team: production incidents, sales requests, and late compliance reviews. The team tests an explicit expedite policy with one owner, then reviews the unplanned work after two weeks.
Formats for different conversations
Use Classic Sprint for a balanced review and Starfish for fine-grained process tuning. DAKI suits operating-model changes, while ROBIN gives complex strategic work more room.
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.