Timeline Retrospective

Map the key events of a project and how the team felt along the way

Try this retrospective live

Key events

What happened, and roughly when? One event per idea.

Early Feb: Project kickoff. We had a clear goal but no agreed definition of done.
Week 3 - Sarah joined from the platform team and took over the API work.
Mid-April: Client asked for the reporting module to be moved into phase one.
High points

When did the team feel at its best, and why?

Around week 8, when the first demo landed well with the client. I finally felt like we knew what we were building.
The two-day hackathon in April. Everyone in one room, no meetings, and we fixed the search problem.
Honestly the best stretch for me was July, once the scope was locked and we could just get on with it.
Low points

When did the team struggle, and why?

Mid-April when the reporting module got pulled forward. We'd just planned the next six weeks and it all went in the bin.
The failed migration in May. Three late nights and a lot of finger-pointing in the channel.
June felt flat. Without a designer we were guessing at the UI and redoing work.
Lessons for next time

What would we repeat or change on the next project?

Repeat the in-person hackathon at least once per project. It broke the logjam on search.
Agree a scope change process with the client at kickoff, including who signs off and how we re-plan.
Do a full dry run of any data migration in a production-like environment before release week.

What is a timeline retrospective?

A timeline retrospective has the team rebuild the story of a long piece of work, such as a project, a quarter or a year, by plotting the events that shaped it in order. The activity comes from the agile retrospectives community. Esther Derby and Diana Larsen describe it as a data-gathering exercise in their book Agile Retrospectives: Making Good Teams Great, and it draws on Norm Kerth's earlier work on project retrospectives. Each person adds the events they remember, puts a rough date on each one and says how it felt at the time. The useful part is the mood line. When you put the team's high points and low points next to the events that caused them, you can see how energy rose and fell over the project: the launch that lifted everyone, the reorg that flattened morale for a month, the late scope change that nobody saw coming. Patterns show up that you would miss in a sprint-by-sprint view, and people who joined partway through get to hear the parts of the story they missed. In TeamRetro, the timeline retrospective template has four topics: key events, high points, low points and lessons for next time. Participants brainstorm individually, then the team groups related ideas, votes on what matters most and closes by agreeing actions with named owners. The format needs enough history to work with, so keep it for the end of a project, quarter or year. For a two-week sprint it isn't worth it, and a simpler format will serve you better.

Timeline retrospective format

Key events

What happened, and roughly when? One event per idea.

Key events are the facts of the story: releases, decisions, people joining or leaving, incidents, deadlines and changes in direction. Ask everyone to add one event per idea and start each with a rough date or week ("Mid-March", "Week 6") so the team can put them in order. A few days before the session, send a prompt asking people to look through their calendars, release notes, tickets and chat history. Memory fades fast, and without this the last few weeks crowd out the early ones. If the early months look thin when ideas are revealed, call it out and give people a couple of minutes to fill the gap.

High points

When did the team feel at its best, and why?

High points are the moments when energy, confidence or morale peaked. Ask people to link each one to a date or a key event and to describe how it felt, beyond what happened. "Shipping the beta felt like a huge relief after weeks of doubt" tells you more than "Beta shipped". Look for what the high points have in common, such as clear goals, good collaboration or visible progress, because those are the conditions worth recreating on the next project.

Low points

When did the team struggle, and why?

Low points are the moments when energy dropped: frustration, stress, confusion or burnout. Ask people to date them and say how they felt, and remind the group that the aim is to understand what happened, not to assign blame. Some people find it hard to name low points in front of a manager, so anonymous brainstorming in TeamRetro helps here. When you discuss them, check whether the dips line up with particular events. Repeated lows around scope changes or handoffs usually point to a process issue worth an action.

Lessons for next time

What would we repeat or change on the next project?

Lessons are where the timeline turns into decisions. Ask people to look at the high and low points together and suggest what to keep doing and what to change on the next project. Push for specific suggestions: "Agree a change process with the client at kickoff" is something you can act on, and "Communicate better" is not. Once ideas are grouped and voted on, turn the top two or three into actions in TeamRetro, each with a named owner and a due date, so the lessons carry into the next piece of work.

When to use this retrospective

  • At the end of a project or major release, when the team wants to look back across the whole effort before moving on.
  • For quarterly or yearly reviews, when there are enough events and enough ups and downs to show a clear mood line.
  • When people joined or left partway through and the team needs a shared picture of what happened and why.
  • After a long or difficult stretch of work, to understand what drained the team's energy and what lifted it.
  • Before kicking off a similar project, to collect lessons the new team can act on. It isn't worth running for a two-week sprint.

Suggested icebreaker questions

  • If this project were a film, what would its title be?
  • What's one small moment from this project that made you laugh?

Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →

Ideas and tips for your retrospective meeting

  • Send a prompt a few days before the session asking people to review their calendars, release notes, tickets and chat history. Without it, recency bias takes over and the last few weeks dominate the timeline.
  • Ask everyone to put a rough date or week at the start of each idea. Dated ideas are much easier to order and group, and they make the rise and fall of the team's mood visible.
  • Encourage people to say how each event felt along with what happened. The emotional side is what sets a timeline apart from a project status report.
  • Use anonymous brainstorming so people can name low points honestly, especially when managers or stakeholders are in the room. Keep the discussion about events and conditions, not individuals.
  • Allow more time than a normal sprint retro. A long project has a lot of history, so plan for 60–90 minutes and timebox each topic so the lessons don't get squeezed at the end.
  • Close with a small number of actions, each with a named owner and a due date. Review them at the start of the next project so the lessons are applied.

Frequently asked questions

What is a timeline retrospective?
A timeline retrospective is a format where the team plots the key events of a project, quarter or year in order, then adds the high points and low points they felt along the way. Comparing events with the team's mood shows what helped and what hurt, and the session ends with agreed actions.
How long does a timeline retrospective take?
Most timeline retrospectives take 60–90 minutes, depending on team size and the length of the period you are reviewing. A year-long review with a large team may need closer to two hours.
Can I use a timeline retrospective for a sprint?
It isn't worth it for a two-week sprint. There are too few events to plot and too little variation in mood, so a simpler format such as Start, Stop, Continue will give you more value in less time.
How is a timeline retrospective different from a post-mortem?
A timeline covers the whole arc of a project, good and bad, and looks at how the team felt as events unfolded. A post-mortem digs into what went wrong, usually after an incident or failure, to find root causes.
How do I stop people only remembering the last few weeks?
Ask participants to review calendars, release notes, tickets and chat history before the session. During brainstorming, point out any thin stretches of the timeline and give people a few minutes to add events from that period.
Why should people date their ideas?
Dates let the team put events in order and line up high and low points against what was happening at the time. That alignment is how you spot patterns, such as morale dropping after every scope change.

Related templates

New Year Kickoff Retrospective

Close out last year and set this year's team goals.

End of Year Retrospective

Look back on your team's year and plan the next one

Project Kickoff Planning

Agree on goals, risks and milestones before work starts.

Project Post Mortem Template

Review any project or incident, capture lessons learned

Ready to run this retrospective?Try this retrospective live