Timeline Retrospective

• After a long project, release or quarter.
• After an incident, to understand the sequence without blame.
• When team members experienced the same period very differently.

Purpose: Reconstruct a sprint, incident, or project chronologically to understand turning points and contributing factors.

• 📍 Events

  What happened?

• 💬 Reactions

  How did the team experience it?

• 💡 Insights

  What did we learn from it?

1. 1

   Set the timeframe · 3 min

   Set the start and end dates of the period you're reconstructing (above the timeline).

2. 2

   Reconstruct events · 8 min

   Ask for facts only: what happened, and when. Fill gaps together; dates can be approximate.

3. 3

   Add reactions · 5 min

   Invite people to add how events felt or affected them. All experiences are valid.

4. 4

   Identify turning points · 7 min

   Walk the timeline left to right. Mark the moments where things changed direction with ★.

5. 5

   Investigate contributing factors · 12 min

   For each turning point ask what contributed — systems, information, timing. Capture insights; avoid blame.

6. 6

   Agree on improvements · 8 min

   Choose actions that would prevent a recurring failure or repeat a good turn.

Notes a software team might write:

Expected outcome: A shared account of what happened, important turning points, and preventive actions.

• Facts first, feelings second, analysis third.
• Gaps in the timeline are often where information got lost.
• Use a blameless lens: people acted reasonably with what they knew at the time.

The facilitator sets the date range; notes sit on a timeline with one lane per card type, can be dragged between days, and turning points can be starred.

Each stage comes with instructions for the facilitator and the participants and a suggested timer you can adjust. Teammates join with a link and their name; no account needed.