Release Retrospective

Choose this exercise

Purpose: Document delivery findings across a project cycle and produce an assigned action plan for the next release.

Use it when: At the conclusion of a product release, major milestone, or Minimum Lovable Product launch involving cross-functional contributors.

Skip it when: For routine sprint retrospectives where a brief team check suffices, or when project work is still in active mid-cycle development.

Group arrangement: Individual silent writing, small groups of 3 to 5 (or pairs if odd numbers leave a remainder of 2), and whole-room review.

Timing: Sources specify 1.5 to 3 hours depending on project size; 90 minutes is structured here as a complete standard session.

Materials and tools

• Sticky notes (three distinct colors, at least 15 notes per person)
• Dark felt markers (1 per person)
• Wall space or whiteboard divided into three labeled sections: What went well during the Project?, What went wrong during the Project?, What could we do differently to improve?
• Dot-voting stickers (3 per person) or digital voting markers on the digital board
• Digital whiteboard template mirroring the three categories if running remotely or hybrid
• Timer or clock visible to participants

Before participants arrive

1. Prepare a physical or digital three-column board labeled: 'What went well during the Project?', 'What went wrong during the Project?', and 'What could we do differently to improve?'.
2. Place sticky notes and markers at every seat or table.
3. Ensure all remote participants have edit access to the digital board before the session starts.

Say this to open

Welcome everyone. We are here to review our recent release across the full project lifecycle. We want to capture what worked well, what did not work, and concrete changes for our next release. Please write specific observations rather than general praise or blame. For example, instead of writing 'communication was bad,' write 'deployment runbook updates were not shared before staging cutover.' You are free to contribute notes quietly, build on posted points, or pass on speaking during open review.

How to run it

1. Introduce scope and review prompts 10 minutes

   Facilitator shares the timeline and scope of the release being reviewed. Read the opening script and present the three board columns: What went well, What went wrong, and What could we do differently to improve. Remind the room that observations focus on process and delivery experience.

2. Silent individual writing 15 minutes

   Participants write observations on sticky notes in silence, one idea per note across the three prompts. Anyone choosing not to write original notes may review project artifacts or build silently on existing board entries. Participants may hand anonymous notes directly to the facilitator during this time to place on the board.

3. Small-group clustering and posting 20 minutes

   Form groups of 3 to 5 people (a pair is fine if room arithmetic leaves two). Groups review their notes, set aside duplicates, and post items into matching board columns along with any anonymous notes placed by the facilitator. Groups cluster related notes together and write a short descriptive header card above each cluster.

4. Thematic review and dot voting 15 minutes

   Facilitator invites a speaker from each group to read aloud their cluster header cards in turn without debate. Give each participant 3 dot-voting stickers or 3 digital dots. Participants place their dots across the improvement clusters they consider most critical to resolve before or during the next release.

5. Action planning 20 minutes

   Select the top 3 to 5 voted clusters from the improvement column. For each item, the room drafts a specific corrective action, assigns a single named owner, and defines when the action must be complete.

6. Debrief and close 10 minutes

   Review the finalized action list with the room. Confirm assigned owners agree with their tasks. Hear 2 to 3 reflections from volunteers using the debrief questions, then state where the action list will be published.

Debrief questions

• Which positive practice from this release must we protect as a standard baseline for the next one?
• Which single process change on our action list will prevent the most friction if completed early?

Finished output: A clustered retrospective board with dot-voted improvement areas highlighted, and an action plan containing 3 to 5 concrete process improvements, each with a named owner and delivery target.

Remote

Use a digital whiteboard with the three prompt columns pre-configured. Keep participants on mute for silent writing. Create breakout rooms of 3 to 5 people to cluster cards on the shared board and label cluster themes. Return to the main room for digital dot voting and record the action table directly in a shared document visible on screen.

Hybrid

All participants use the shared digital board so all notes remain unified in real time. Remote attendees form digital breakout rooms of 3 to 5, while in-person participants form physical clusters using laptops or designated typists to post to the same board. Whole-room review and voting occur simultaneously on the shared screen.

Access and participation choices

• Participants may submit notes anonymously via a private digital form or by handing unlabeled notes to the facilitator before clustering begins.
• Speaking during whole-room review is optional; participants may contribute solely through written notes and dot votes.

If the session gets stuck

Participants focus exclusively on complaints without proposing actionable improvements.

Pause the discussion and direct the room to convert each highlighted problem into an explicit proposal for the third column: 'What could we do differently to improve?'

Action items are too vague to track, such as 'improve cross-team communication.'

Ask the group: 'What specific artifact, meeting, or checklist item changes so we know this happened next time?' Do not record the action until an owner and verifiable deliverable are named.

Terms used here

• MLP: Minimum Lovable Product; an initial product release that delivers enough value and quality to satisfy early users.
• Runbook: A routine compilation of procedures and operations needed to deploy and maintain software successfully.