The Year-in-Review Slide: Showing What Your Team Actually Shipped

Sometime in November, the ask lands. Maybe it's for the leadership offsite, maybe it's the first slide of the 2027 planning deck, maybe it's your own performance review. The wording varies, but the request is the same: show us what the team shipped this year, on one page.

Most people answer it with a bullet list. Ten lines, one per project, in roughly chronological order. It's accurate, it's quick, and it quietly undersells a year of work. This guide is about the better version — a year-in-review timeline slide — and how to build one from the task history you already have.

Why the bullet list undersells your year

A bullet list flattens time. "Shipped the billing migration" reads identically whether it was a six-week sprint or a nine-month grind that ran underneath three other launches. The list hides the thing that actually made your year hard and impressive: how much of it overlapped.

A timeline makes that visible without you saying a word. Leadership sees the migration bar running from February to October, the two product launches landing on top of it, and the Q3 gap where the reorg ate a month. Nobody has to claim the team "did a lot" — the shape of the year makes the argument.

There's a second reason the timeline wins: executives have been reading your status reports all year, one reporting period at a time. The year-end review is the only moment they see the whole thing at once. A format that shows sequence and parallel work uses that moment; a list wastes it.

Decide what the slide has to prove

Before you open any tool, decide what the one slide is for. A year-in-review usually has three jobs, and knowing which one matters most changes what you include.

First, throughput: showing the team shipped steadily all year, not just in a December push. If that's the job, the spread of delivery dates matters more than project detail.

Second, deliberate sequencing: showing the platform work landed before the product work it unblocked. If that's the job, the dependencies between bars are the story, so group related work into the same lane.

Third, the setup for next year: a review that ends with "and that's why the 2027 ask is X" needs the unfinished bars visible, running off the right edge of the slide into January.

Whichever job it is, keep it to three to five workstreams. More than that and the slide stops being executive. Name projects the way your audience names them, not the way your issue tracker does.

Pull the raw material from tools you already have

You don't need to reconstruct the year from memory. The record exists in the tools you've been using: closed epics in your tracker, release notes, launch announcements, the dates on your own status reports. Reduce all of it to a plain task list — the same shape Tymepath imports directly:

1. One row per project or major phase: a name, a start date, an end date.
2. A workstream label on each row (Platform, Product, Operations — whatever your three to five lanes are).
3. Launches, go-lives and other single-day moments flagged as milestones rather than ranges.
4. Month-level precision. Nobody at the offsite will check whether discovery started on the 3rd or the 9th, and chasing exact dates is where this exercise usually dies.

Fifteen to twenty-five rows is plenty for a full year. If you're well past that, you're listing deliverables, not projects — roll them up.

Turning the list into the slide

Here's the walkthrough in Tymepath, which is built for exactly this task-list-to-slide step.

Create a project and import your list — CSV and Excel both work, or paste rows straight into the task table. Put the workstream label in each task's group field; groups become the lanes on the slide, so your three to five workstreams draw themselves as three to five rows.

Switch the view to Quarter. Day- or week-level views are for plans in motion; a retrospective reads best when Q1 through Q4 are the only gridlines, because that's the resolution your audience thinks in.

Flag the launches as milestones so they render as markers instead of bars. A year-in-review lives on these — the bars say "we worked," the milestone markers say "and here is where it landed."

Pick a style that matches the room. Tymepath has 17 visualization styles; for a leadership audience the quarterly roadmap and milestone-focused styles keep the slide calm, and a theme sets the palette so it doesn't look like it escaped from an issue tracker.

Then the part that matters in practice: the slide redraws from the table. When someone reviewing the draft says "didn't the pricing launch land in June, not July?", you change one cell and re-export, rather than nudging rectangles in PowerPoint at 11pm before the offsite. Export as PNG or PDF, or as a PowerPoint (.pptx) slide that drops straight into the deck it was always destined for.

What to leave off

A few things make year-in-review slides worse and are worth deleting on sight.

Cancelled work, unless killing it was the win — in which case give it a bar that visibly stops, because a deliberate kill is a decision worth showing. Internal deliverables that only your team would recognize. And false precision: if a date is approximate, round it to the month and move on. The review is a shape, not an audit.

One slide. If it doesn't fit, the workstreams are too granular — not the font too big.

Build yours before the ask lands

The year-in-review request is coming whether you prepare or not, and the version built in an afternoon in November beats the one assembled in a panic the night before the offsite. Your task history already holds everything the slide needs; the only work is giving it a shape.

If the review is the setup for next year's plan, pair it with our guide to turning strategy soup into a 2027 roadmap slide.