Posts

We Analyzed 1 Million Retro Cards. Here's What Teams Actually Complain About

Ask anyone what goes wrong on software teams and you'll get the same answer: communication. It's the default diagnosis in every agile book and roughly half of LinkedIn. The cards say otherwise. We aggregated every retrospective ever run on Kollabe: 86,977 boards and 1,071,253 cards, written by real teams between October 2023 and July 2026. Then we measured what teams complain about when nobody is writing a think piece. Everything here is aggregate analysis, theme counts, vote counts, and completion rates. No individual card is quoted or identifiable. A quick note on method: we classified columns as positive or negative by their names ("What Went Well" vs "What Went Wrong", "Glad" vs "Mad", and so on), which gave us 254,653 complaint cards to work with. Themes were bucketed by keyword matching, with a pgvector embedding index to sanity-check the buckets semantically. Keyword matching is English-centric and conservative, so every percentage below is a floor, not a ceiling.

The complaint league table

Here's what teams write in the negative column, ranked by share of all 254,653 complaint cards: Communication, the thing we all supposedly struggle with most, ranks eleventh, on 1.9% of complaint cards. Teams complain about testing more than five times as often. Even Jira, as a named tool, shows up on 1.2% of cards, nearly as often as communication. That doesn't mean communication is fine. It means that when teams describe their problems in their own words, they name concrete stages of the delivery pipeline: the tests that weren't written, the ticket that had no acceptance criteria, the release that slipped. "Communication" is what those problems get labeled as later, once the details have been forgotten. One more wrinkle: testing is also the second most common thing teams praise (7.6% of positive cards, behind teamwork at 13%). Testing isn't a villain; it's the part of the process teams watch most closely, in both directions.

What teams write isn't what they vote for

Volume tells you what's on people's minds. Votes tell you what they want fixed. The two disagree. The average complaint card collects 0.64 votes. Some themes punch far above that:

• Code review and PRs: 0.80 votes per card. The most voted complaint theme in the dataset, 25% above baseline.
• Workload and burnout: 0.79. Only 1% of cards mention it, but when someone does, the room votes.
• Scope creep and tech debt: 0.77 each. Rarely written, heavily backed.

Testing, the volume champion, gets 0.63 votes per card, slightly below average. Teams write about testing constantly but rally around review bottlenecks, overload, and debt when it's time to pick what to fix. Two other voting facts worth knowing. Teams vote on problems 36% more than on wins (0.64 vs 0.47 votes per card), so retros really are for fixing things. And 76% of complaint cards get zero votes, which is the strongest argument for voting on items at all: without it, every card looks equally important.

Complaints are sticky

We looked at 9,250 pairs of consecutive retrospectives run by the same team and asked: if a theme shows up this retro, how likely is it to show up next retro? Every single theme repeats at above its base rate. The stickiest:

Theme	Base rate in any retro	If it appeared last retro	Multiplier
Communication	9.1%	21.3%	2.3x
Workload and burnout	5.8%	10.9%	1.9x
Meetings	12.1%	21.6%	1.8x
Documentation	10.8%	19.0%	1.8x
Code review	16.8%	29.2%	1.7x
Tickets and requirements	31.7%	47.3%	1.5x

Communication tops this table. Teams rarely complain about it, but the ones that do tend to stay stuck with it. Process complaints like tickets and testing recur partly because they're common everywhere; communication recurring at 2.3x its base rate suggests something harder to dislodge. If the same card keeps reappearing, the retro isn't failing to find the problem. It's failing to fix it. Which brings us to the uncomfortable part.

The action item gap

Only 19.6% of retrospectives produce a single action item. Four out of five boards full of votes and discussion end with nothing written down to do about it. And the action items that do get created mostly stall: 68.7% still sit in pending, 13.2% are completed, and 12% were deleted outright. But the data shows exactly what separates the completed ones: Action items with an assignee get completed 23.2% of the time versus 8.6% for unowned ones. Due dates work even better, at 37% completion, yet almost nobody sets them. These are the two cheapest interventions in this entire dataset: say a name and a date out loud before the meeting ends. We've written a full guide on making retrospective action items stick if this is where your team leaks value.

Anonymity doesn't unleash negativity

A common worry about anonymous retro cards: turn on anonymity and the board becomes a complaint wall. The data says no. About 5.8% of all cards are posted anonymously. Their negative share is 22.7%, slightly lower than the 23.8% for named cards. People don't save their harshest feedback for anonymous mode; they mostly use it to say the same things without worrying about how it lands. If your team hesitates to turn it on, this is evidence it won't make your retro toxic. For teams still building psychological safety, it's a low-risk way to hear from quieter voices.

Smaller findings we didn't expect

• The median gap between retros is exactly 14 days. 46% of teams run biweekly, 19% monthly, 13% weekly. The two-week sprint is alive and well. (More on picking a cadence in how often to run retros.)
• Complaining takes more words. The median complaint card is 65 characters; the median positive card is 54. Problems come with context; praise comes as a high-five.
• There are a thousand ways to say "review my PR." Using the embedding index, we found over 1,000 cards that are near-paraphrases of a single sentence: "pull requests sitting too long waiting for code review." The 1,000th nearest match is still unmistakably about slow reviews.
• The average retro: 5.8 participants, 15.4 cards, 3.4 columns. If yours looks like that, you're normal.

What to do with this on Tuesday

The dataset points to three moves any facilitator can make immediately:

1. Chase votes, not volume. The most-written theme and the most-voted theme are usually different. Discuss the top-voted cards first, and treat a low-volume, high-vote card (workload, tech debt) as a signal worth double its size.
2. Convert before you close. The single biggest leak isn't bad discussion. It's the 80% of retros that end with no action item. One owned, dated action item beats five orphaned ones.
3. Track repeats. If a theme appears two retros in a row, stop treating it as feedback and start treating it as a project. Sticky complaints don't leave on their own.

If you want to see how your team compares, run your next retro on Kollabe's free retrospective boards, or browse the live retrospective statistics this post draws from. And if your board format has gone stale, the retrospective template generator can build a custom one in seconds.