The 3 Retro Metrics Worth Tracking (and the Ones That Lie)
Open the analytics tab in almost any retro tool and you get a dashboard. Participation rate, average sentiment, cards per person, action items created, time spent per column. It looks like rigor.
Most of it is decoration.
The trouble with measuring retros is that the easy things to count are not the things that matter, and the things that matter are annoying to count. So teams track whatever the tool hands them, the chart goes up and to the right, and the retros keep producing nothing. A green dashboard sitting above a team that fixes the same bug every sprint is not data. It is theater.
Here are the three numbers actually worth your attention, and the popular ones quietly wasting it.
Most Retro Metrics Are Theater
There is a useful distinction borrowed from product analytics: vanity metrics versus actionable ones. A vanity metric looks impressive and moves in ways you cannot act on. An actionable metric ties to a decision. If a number goes up and you have no idea what to do differently, it is vanity, however nice the chart looks.
Retro dashboards are full of the first kind. Attendance, sentiment scores, sticky-note counts. None of them tell you the only thing that matters, which is whether anything changed. A retrospective is there to produce improvement, which is the whole point of running one well. So the metrics that count are the ones that measure improvement, not the ones that measure the meeting.
Metric 1: Did Last Sprint's Actions Actually Happen?
If you track one thing, track this. Of the action items your team committed to last retro, how many were done by this one? It is a single fraction, three of five, and it is the closest thing a retro has to a north star.
Completion is where retros live or die. Easy Agile found that across its TeamRhythm users, teams were finishing only 40 to 50 percent of the actions they wrote. Once the product started surfacing and nudging the open ones, that number climbed to 65 percent. A healthy target sits north of 80 percent.
A low rate does not mean your team is lazy. It usually means you wrote too many items, or wrote them too vague to start. Two finished changes beat ten endorsed and abandoned. We pulled apart the whole follow-through problem in why half your retro action items never get done; the short version is that this metric is mostly a scoreboard for how well you write commitments.
Watch the trend, not the snapshot. One rough sprint tells you nothing. A completion rate that sits under half for three sprints in a row is telling you the retro generates talk, not change, and no new format will fix that until the items themselves get smaller.
Metric 2: Is the Same Problem Back Again?
Completion tells you the team did the thing. It does not tell you the thing worked. For that you need a second number, and it is the one almost no tool will hand you: how often the same theme comes back.
Tag your retro themes loosely. Flaky tests, unclear requirements, slow code reviews, whatever your team keeps circling. Then each retro, count how many of this sprint's top issues also showed up last time, or the time before. A problem that reappears after you supposedly fixed it is the most valuable signal a retro produces, because it means the fix missed the real cause.
Say "flaky CI" lands on the board four retros running. The team is not failing to act. It is acting on a symptom. That is your cue to stop generating fresh action items about it and run a proper root-cause session instead, or switch to a format built for digging into one problem rather than skimming ten. Our guide to retro formats covers the ones that go deep.
Most retro tools will not chart this for you. You usually end up tracking it by hand in a spreadsheet, or leaning on a tool with real cross-retro analytics like ScatterSpoke, which is built around spotting patterns across many retros rather than running one good-looking board.
Metric 3: One Delivery Signal You Already Have
The first two metrics live inside the retro. The third lives outside it, and it keeps the other two honest.
Pick one delivery number your team already produces and watch it over time. Cycle time, the days from starting a work item to shipping it, is the best default for most teams. If your retros are working, the process changes you make should eventually show up here. If cycle time is flat for a quarter while your completion rate is high, you are completing the wrong actions.
A few caveats. These are lagging indicators. The DORA metrics, lead time, deploy frequency, change failure rate, and time to restore, all reflect the past few weeks of your delivery system, not last Tuesday's retro. Read them sprint to sprint and you will just chase noise. Look roughly once a quarter, long enough for a real change to surface.
And do not bolt on five of them. One number you actually open beats a delivery dashboard nobody does. Tools like GoRetro that wire the retro into sprint and delivery data make this easier, but a spreadsheet and a quarterly glance work fine.
The Metrics That Lie
Everything else on the dashboard is, at best, context, and at worst a distraction dressed up as insight. The usual suspects:
- Attendance and participation rate. A full room saying safe, forgettable things is not a healthy retro. You can hit 100 percent on both and change nothing.
- Number of action items created. More is worse, not better. A retro that spits out twelve actions belongs to a team that will finish none of them. Count what gets done, never what gets written.
- Velocity as an improvement metric. Velocity measures output and is trivially gamed by inflating estimates. A retro that 'improves velocity' often just taught the team to point more generously.
- Cards per person. Volume of input is not quality of insight. One sharp observation that changes how the team works beats forty stickies that go nowhere.
The pattern across all four is the same. They count activity, and activity feels like progress, so they are comforting to put on a screen. None of them move when the team actually gets better, and none of them move when it gets worse, which makes them useless for the one job a metric has.
Team morale belongs here with an asterisk. A quick pulse check is genuinely useful. But the moment you put a morale score on a tracked dashboard and start managing the line, people learn to give the answer that keeps it green. Read the room, do not chart it. The honesty you lose is worth more than the trendline you gain.
None of the three metrics worth keeping need a special analytics suite. A completion fraction, a tally of repeat themes, and one delivery number you already have. If your tool's dashboard cannot show those three and insists on showing you fifteen others instead, that tells you something about the dashboard, not your team.
Find a tool that measures what matters
Compare how 17 retrospective tools handle action tracking, recurring themes, and delivery data, so your dashboard reflects real improvement instead of vanity numbers.
Browse All Tools