Every two weeks, your team fills out the same three fields. What went well. What didn't. What should change. It takes about ten minutes, usually happens on Friday afternoon, and produces data so thin that no one reads it a week later.
The sprint retro is the most common recurring form in engineering organizations. It's also the one most likely to produce answers indistinguishable from noise. Not because people don't care about their work. Because the form asks them to do something humans are bad at, under conditions that make it worse.
The recency problem
A standard sprint is ten working days. The retro form asks about all ten. But the person filling it at 4:55pm on a Friday is not reconstructing ten days of work. They're remembering the last two.
This isn't speculation. Murphy and Cleveland documented it in Understanding Performance Appraisal (1995): when people evaluate a period of work from memory, recent events receive disproportionate weight. The Monday deploy that went flawlessly, the Wednesday bug that burned four hours of the team's time, the Thursday code review that caught a security flaw — all compressed into a blur labeled “fine.” Friday's merge conflict, which took 20 minutes to resolve, dominates the narrative because it's the last thing that happened.
Attention density · 2-week sprint retro (filled Friday 4:55pm)
Murphy & Cleveland (1995): recent events dominate recall-based evaluation.
Derby and Larsen identified this in Agile Retrospectives (2006) as one of the core failure modes of the format. Their recommendation: use artifacts. Pull up the board, walk through the tickets, look at the actual timeline. Most teams skip this step because the meeting is already 30 minutes long and everyone wants to leave.
The form, sent asynchronously, has no artifacts at all. Just a blank textarea and a deadline.
The timing problem
Folkard and Monk published research in 1980 on time-of-day effects in cognitive performance. Complex recall tasks — the kind that require you to synthesize information from multiple sources and form a judgment — degrade measurably in the late afternoon. Working memory narrows. Retrieval becomes less thorough. People default to whatever is most available, which is whatever happened most recently.
Sprint retros are almost always filled in the late afternoon on the last day of the sprint. The form is demanding peak cognitive effort at the exact moment when that effort is hardest to produce.
The result is predictable. “Went well: shipped the feature. Didn't go well: some blockers. Change: nothing comes to mind.” This is not someone who doesn't care about their team. This is someone whose working memory has narrowed to the last 48 hours and whose cognitive budget for the day is spent.
What the data actually looks like
Pull up your last four sprint retros and read the responses side by side. You'll find a pattern: the same three or four people write substantive answers every time. Everyone else writes one sentence per field, if that. The substantive answers reference specific events with dates. The thin answers reference nothing.
This isn't a motivation gap. It's a recall gap. The people writing good retro answers are the ones who happen to remember what happened — because they kept notes, or because the events were emotionally salient, or because they looked at the ticket board before filling in the form. Everyone else is satisficing: picking the first plausible answer that lets them close the tab.
Krosnick (1991) described this behavior in survey respondents generally. In the retro context it means your sprint data is systematically biased toward whatever happened in the last two days, filtered through the memory of whoever happened to remember the most. Decisions made on this data — what to prioritize next sprint, which processes to change — are built on a foundation that's missing 80% of the picture.
What changes when the form has context
The fix isn't motivational. It's informational. The respondent doesn't need encouragement to write better answers. They need the raw material.
Pluck's AI pre-fill reconstructs the sprint timeline from the tools where the work actually happened: merged PRs in GitHub, closed tickets in Linear, relevant threads in Slack. The draft that lands in the retro form mentions Monday's deploy and Wednesday's bug — not just Friday's merge. It includes dates, ticket numbers, and specifics the respondent would never have recalled on their own.
AI-reconstructed timeline · from GitHub + Linear + Slack
The respondent reads the draft. Fixes the one thing the AI got wrong. Adds the context only a human would know — the political subtext of that Slack thread, which win the team lead should hear about. Submits in ten seconds.
The cognitive task changed. It's no longer “reconstruct ten days from memory at 4:55pm on a Friday.” It's “review a two-paragraph summary and correct what's off.” Recognition, not recall. And recognition accuracy holds steady regardless of time of day or fatigue — Shepard (1967) showed 98% recognition rates even under suboptimal conditions.
The retro form doesn't need a redesign. It needs information the respondent already has, surfaced at the moment they need it. See how it works for retros and other recurring forms →