| name | itk-retro-rundown |
| description | A structured, facilitated conversation that helps a team reflect on a completed activity or event by comparing what was expected with what happened and identifying concrete improvements. |
| intent | Refine processes and strengthen what’s working. Improve performance against specific objectives. Discuss challenging topics constructively (e.g., “what isn’t working well”). Build shared understanding to better analyze issues and decisions. |
| type | component |
| phase | evaluate |
| outcome | evaluate |
| difficulty | beginner |
| group_size | 4+ people |
| time_required | 45+ minutes |
| best_for | ["Sprint retrospectives where the team needs to surface systemic friction before committing to next iteration's process changes","Post-launch reviews after a major release to compare expected outcomes against actual adoption and team experience","Quarterly OKR wrap-ups to evaluate what drove or blocked objective progress before setting next cycle's goals","Post-mortems on a missed deadline or sponsor escalation where blame risk is high and trust is fragile","End-of-discovery-phase reflection to capture process learnings before transitioning into delivery"] |
| sources | ["MITRE Innovation Toolkit (ITK)","https://itk.mitre.org/toolkit-tools/retro-rundown/"] |
Retro Rundown
What Is It
A structured, facilitated conversation that helps a team reflect on a completed activity or event by comparing what was expected with what happened and identifying concrete improvements.
Why Use It
Refine processes and strengthen what’s working. Improve performance against specific objectives. Discuss challenging topics constructively (e.g., “what isn’t working well”). Build shared understanding to better analyze issues and decisions.
When to Use It
After any completed activity or event—large (final presentation, end-of-year deliverable) or small (sponsor check-in, weekly team sync). The sooner after the activity, the better.
How to Do It
- Event Data: Complete the basic information about the event, project, or activity.
- Project Check-in: Each team member creates a sticky note with their name. Choose an icon that reflects how you’re feeling about the project and place it under your sticky. Invite everyone to share a brief explanation.
- Pass out red (rose), green (bud), and blue (thorn) sticky notes to participants and have them write the strengths, opportunities, and challenges associated with the topic. If colored sticky notes are not available, use red, green, and blue markers with plain sticky notes, or use a whiteboard with colored markers. Optional: Use the Rose, Bud, Thorn worksheet as your guide.
- Encourage participants to generate multiple issues, insights, or ideas, but to capture only one per sticky note.
- Group the colored sticky notes on a whiteboard or similar surface according to rose, bud, and thorn.
- If desired, participants can group or cluster items further by priority or related themes and give each group a title.
Key Concepts
Rose, Bud, Thorn — A color-coded framing where roses are strengths/wins, buds are emerging opportunities worth nurturing, and thorns are challenges or friction. It forces balanced reflection rather than a gripe session or a self-congratulatory recap.
Expectation vs. Reality Gap — The core analytical move of comparing what the team planned or assumed against what actually happened. Naming this delta is where most actionable retro insights originate.
Project Check-in (Emotional Pulse) — An opening round where each person signals how they feel about the work via an icon and brief share. It surfaces morale and psychological safety signals that quantitative metrics miss.
Affinity Clustering — Grouping individual sticky notes into themes so recurring issues become visible as patterns rather than isolated complaints. Clustering separates systemic problems from one-off noise.
Action Conversion — Translating retro observations into owned, tracked action items with accountability. Without this step the retro produces venting instead of process change, and participation degrades over time.
Blameless Framing — Structuring the conversation around systems and processes rather than individuals, so people surface real failures honestly. Essential for retros covering missed targets or interpersonal friction.
PM Applications
- Run a sprint retrospective at the end of each iteration to capture process friction and feed concrete improvements into the next sprint planning session.
- Facilitate a post-launch review after shipping a major feature, comparing roadmap assumptions and success metrics against real adoption and engineering effort.
- Conduct a quarterly OKR retrospective to evaluate which key results were over- or under-scoped before drafting the next quarter's objectives.
- Hold a blameless post-mortem after a missed deadline or production incident to identify systemic causes and prevent recurrence in delivery.
- Debrief a stakeholder or sponsor engagement to assess what built or eroded trust, informing how you prepare future executive briefings.
- Reflect at the close of a discovery phase to capture research process learnings before the team transitions into delivery and backlog refinement.
Benefits
- Easiest tool to explain Participants catch on very quickly Very easy to come up with ideas
Common Pitfalls
- Ending the session at clustered sticky notes without assigning owners and due dates—participants conclude their input is ignored and disengage from future retros.
- Letting thorns dominate while roses get a token mention, which demoralizes the team and obscures the working practices worth protecting and scaling.
- Running retros only after large failures instead of regularly—infrequent retros become high-stakes blame sessions rather than routine tuning.
- Allowing senior voices to anchor the conversation first, biasing the input and suppressing junior or dissenting observations that hold the real signal.
- Treating buds as vague wishes rather than testable opportunities, so promising ideas never get scoped, prioritized, or converted into backlog items.
- Skipping the emotional check-in to 'save time,' missing morale and psychological-safety signals that explain why a project underperformed despite hitting metrics.
Combine With
Trimming to narrow down buds the team wants to take action on
Assets
Metadata
| Field | Value |
|---|
| ITK Phase | EVALUATE |
| Difficulty | Beginner |
| Group Size | 4+ people |
| Time Required | 45+ minutes |
| Source | itk.mitre.org |
