What to Bring Up in a Retrospective: Topics That Matter

TL;DR: The retro's job is to find the biggest leak in the system and change one thing about it. So the topics worth bringing up are the ones with a leak attached: the stage that grew, the work that waited, the tickets that bounced back, the plan that didn't survive, the reviewer who carried the whole queue, the after-hours creep. Bring one, with a concrete example, phrased as a question about the system. Leave individual performance at the door, and leave the room with exactly one experiment.

You're sitting in retro, the facilitator asks "what didn't go well?", and the room offers the same three sticky notes as last time: communication, estimation, "too many meetings." None of it is wrong. None of it is actionable either. The problem usually isn't willingness. "What should I bring up?" is genuinely hard to answer from memory, because memory surfaces the freshest irritation, not the biggest leak. This is the concrete list. (For the meeting format, how to run a retro on evidence with the guardrails, see data-driven retrospectives. This article is about the what.)

The principle: bring leaks, not vibes

A good retro topic has three properties: it's about the system (a queue, a process, a batch size), it comes with a concrete example (a PR, a ticket, a date), and the team could run an experiment on it next cycle. "Communication" fails all three. "The payments PR waited three days for first review - what made pickup hard this cycle?" passes all three. Same underlying issue; only one of them can change anything.

Where the time went

The highest-value topic family, because elapsed time is mostly waiting and waiting is mostly invisible until someone points at it.

• The stage that grew. Which part of cycle time got worse this cycle: coding, pickup, review, deploy wait? A stage that doubled is a retro topic by definition. Phrase it: "Review wait doubled in week two - what happened that week?"
• The pickup queue. How long did finished work sit before first review? There are published reference points that turn this from opinion into map-reading: LinearB's benchmarks band pickup time from under an hour (elite) to over 16 hours (needs focus), and Google's study of ~9 million reviewed changes found a median first response under 4 hours. Phrase it: "Our pickup p75 was two days - what would make picking up reviews easier than starting new work?"
• Blocked and aging work. What's the oldest in-flight item, and how long has "blocked" been blocked? This is the WIP conversation arriving with receipts. Phrase it: "Three items have been in progress for over three weeks - do we finish, split, or kill them?"
• The stuck one. Pick the single most painful item of the cycle and walk its timeline: where did the days actually go? One honest trace teaches more than any average.

What came back after "done"

• Reopened tickets and bounce-backs. Things that left Done and returned. Was it unclear acceptance criteria, missing tests, or a "Done" that means "mostly"? Chronic looping is a definition problem.
• Rework and hotfix follow-ups. Shipped-then-rewritten within days. Phrase it: "Two of our eight merges needed a fix within the week - what did the first pass miss, and would a checklist have caught it?" Worth taking seriously: DORA's 2023 report found teams with faster code review report ~50% higher delivery performance. Quality practices and speed travel together.
• CI flake and pipeline pain. How many red builds were the code's fault versus the pipeline's? A flaky suite taxes every single PR and never appears on any board.

Planning and scope

• The plan-vs-reality gap. What share of what was planned actually finished? Chronic carryover means the plan is fiction, and that's a sizing conversation.
• Silent intake. How much work arrived mid-cycle that nobody planned? Often the entire gap between planned and done, and invisible without decent board hygiene. Phrase it: "A third of what we shipped wasn't in the plan - where did it come from, and should it have a lane?"
• The item that was never ready. The ticket everyone dreaded because nobody knew what "done" meant. What would a ready-check have caught?

Collaboration and review

• Review load concentration. Did one person carry most of the reviews? That's a bottleneck and a bus-factor risk, a systemic pattern worth naming while it's cheap. Phrase it: "Anna did 14 of 20 reviews - how do we get a second reviewer comfortable in that area?"
• Rubber-stamp signals. Large diffs approved in minutes with no comments: is review actually happening, or just being recorded?
• Oversized PRs. If reviews were slow, were the diffs reviewable? (LinearB's elite band is under 100 changed lines.) Batch size is a topic the author-side of the room controls.
• Docs and context gaps. Did anyone lose a day re-deriving context that should have been written down? That's a topic, with the day as the receipt.

The human layer

• After-hours and weekend creep. Did the cycle finish on evening work? Say it out loud before it's a burnout pattern. Crunch that goes unnamed becomes policy by default.
• Interrupt load. Who got context-switched the most, and can the interrupt lane be made explicit instead of ambient?
• Feel vs. facts. "The numbers look fine but this cycle felt terrible" is a fully valid retro topic. Timestamps don't measure morale, and divergence between the two is signal.

The meta topic (bring it every time)

Did last retro's experiment happen, and did it work? First agenda item, always. A retro whose actions quietly evaporate trains the team that the meeting is decorative, and that lesson, once learned, is expensive to unlearn.

What NOT to bring up

• Individual performance. A person's output, speed, or mistakes belongs in a 1:1 with context, never in a group session. The retro runs on people volunteering embarrassing truths, and the moment output metrics get names attached, that supply ends. Roast the system, never the person.
• Things nobody in the room can change. The reorg, the market, last year's architecture decision. Venting has value, but cap it and move to a leak you can act on.
• Anything you won't experiment on. A topic with no possible action is a mood, and relitigating settled decisions with no new information is a hobby.

How Busfactor fills the topic list for you

The honest failure mode of everything above: it requires someone to know the pickup p75 doubled and find the PR that waited three days. That's an hour of archaeology before every retro, which is why most retros run on memory instead. This is precisely the prep Busfactor automates, and the pitch is direct: it connects to GitHub, your board, and CI, and the topic list assembles itself as evidence-linked findings. The stage that grew, aging and zombie work, ticket loops (reopened-after-Done, counted with receipts), the PRs that struggled ranked by five deterministic signals judged against your own org's percentiles, review-load concentration, after-hours creep. Each arrives with the receipts attached and both readings on the table - a spiked pickup queue is presented as "release freeze, or reviewer pool of one?" rather than a verdict - because the double-edged framing is exactly what a retro topic should be. The guardrails match the meeting's safety requirements: findings roast queues, never people, and anonymization is built in for anything that leaves the room.

The limits, honestly: Busfactor knows what and where, never why. The chart can say pickup spiked; only the room knows it was the incident plus two people out. It won't facilitate, and it can't measure how the cycle felt. It just makes sure that when your team spends its retro hour, it spends it on the biggest leak with the receipts already on the table, instead of on whichever annoyance happened most recently.