A retrospective is only as useful as what people are willing to write in it. When someone suspects their name is attached to "the release process is chaos because of how we plan", they write "communication could be better" instead, and the retro produces nothing.
That is why so many retro tools offer an "anonymous" mode. The trouble is that the word covers very different things, and most teams never check which one they are getting. This guide is about the difference, and about the other half of a useful retro: following through on what it decides.
Five ways anonymity leaks
A card can be hidden from the screen and still be traceable. These are the usual leaks, from the most technical to the most human:
- The author is stored. The card appears without a name, but the tool's database records who wrote it. Anyone with admin access, a data export or a support ticket can find out. This is the most common case, and the least visible.
- The order gives it away. If cards are revealed in the order they were written, the person who was typing at 10:02 wrote the card that appeared at 10:02.
- Live activity gives it away. "3 cards added", typing indicators, or a card counter that ticks up the moment one person stops typing. In a team of six, that is enough.
- Timestamps give it away. A visible "added 2 minutes ago" does the same job as a live counter, just later.
- Style gives it away. In a small team, people recognise each other's phrasing and topics. No software can prevent this one; it can only avoid adding the other four on top.
A useful test: ask the vendor, or read the privacy documentation, for the answer to one question — "If our Jira admin wanted to know who wrote a specific anonymous card, could they?" If the honest answer is "technically yes, but they wouldn't", the cards are private, not anonymous.
A checklist for any retro tool
| Question | What a good answer looks like |
|---|---|
| Is the author of an anonymous card stored anywhere? | No. Or, if it must be kept while the retro is open so people can edit their own cards, it is deleted when the retro closes. |
| In what order are cards revealed? | Random, and without times. |
| What do participants see while others are writing? | Nothing that changes when one person adds a card. Who is present, perhaps; not counts. |
| What happens to individual votes? | Only totals are kept after the retro ends. |
| Where is the data kept? | Ideally inside your Atlassian instance, rather than on the vendor's servers. |
| Who can open a given retro? | The team it belongs to, not everyone who can browse the project, unless you choose that. |
Running the retro
The format matters less than the sequence. Whatever columns you use — Went well / To improve, Start / Stop / Continue, Mad / Sad / Glad — the steps that make a retro work are the same:
- Review last time's actions first. Five minutes, before anyone writes anything. It is the single most effective habit in this whole guide, and the one most teams skip.
- Write privately. Everyone at once, with a timebox. Nobody sees anything yet.
- Reveal and group. All cards appear together. Group the ones that say the same thing, but keep each card's own words.
- Vote. Three votes each is usually right. Totals stay hidden until voting ends, so the first votes don't steer the rest.
- Discuss the top few, and decide actions. One to three actions, each with an owner. More than that and none get done.
The part that makes retros worth it: actions
The most common complaint about retrospectives is not a lack of anonymity. It is "we say the same things every time and nothing changes". That is almost always a follow-through problem, and it has a mechanical fix:
- Make every action a Jira issue, in the backlog the team actually works from, with an owner. An action that lives in a retro board or a slide is an action nobody sees again.
- Keep only the action text in the issue. The cards that led to it stay in the retro; the issue should not quote anyone.
- Bring open actions back at the next retro with their live status, and decide explicitly: done, still in progress, or dropped. Dropping an action on purpose is fine. Forgetting it is the problem.
- Keep actions per team. If two teams share a Jira project, each should review only its own.
Retrospectives for Jira, our app, is built around this guide. Anonymous cards are stored without their author, and the codes that let people edit their own cards are deleted when the retro ends. Cards are revealed in random order, without times, and nothing changes on screen when someone adds a card or a vote. Actions become Jira issues created as you, and come back at the start of the team's next retro. It runs entirely on Atlassian infrastructure. It is currently in Atlassian Marketplace review.
One caveat
Anonymity lowers the cost of honesty; it does not create trust. If people fear consequences for what they say in a retro, the fix is in how the team is led, and a tool can only avoid making it worse. In very small teams, be explicit that style can give an author away, so nobody is surprised.