The Symptom and Its Wrong Diagnosis

You've probably been in this retrospective. Maybe you've run it.

Sprint's done. The team gathers. Someone draws a column on the whiteboard: "What can we improve?" The answers come: the standup takes too long, the tickets weren't clear enough, deployment was manual. And then, almost always, one that lands without much pushback: "We need to communicate better."

Everyone nods. The facilitator writes it down. The action item goes into the notes.

I ran this retrospective for two years before I understood the diagnosis was wrong - not completely wrong, but wrong in the way that matters. The team wasn't miscommunicating because they were bad at communicating. They were miscommunicating because they had built a feature on top of an assumption nobody had ever checked. And by the time the miscommunication surfaced, that assumption was seven sprints deep.

The sprint where it went wrong wasn't sprint 7. It was sprint 1. Nobody recognized it because in sprint 1, nothing looked wrong.

A normal story

Sprint 1, backlog refinement. A card goes up:

"As a user, I want to be able to export my data."

Everyone nods. Three story points. The card goes into the next sprint.

Nobody asks: which user? Which data? In what format? For what purpose?

In hindsight, this sounds careless. In the moment, it sounds like a normal story - short, clean, apparently clear. There are 25 more items in the backlog. The refinement has 15 minutes left. The story is "clear enough."

It isn't.

Sprint 4: a developer picks up the story and starts implementation. At the daily standup, first question: "Is this supposed to be a CSV or Excel?" The PO says: "Both, I think." Short discussion. They work it out over Slack: three messages, spread over eleven hours. No update in the backlog tool. No record anyone will find in three weeks. Just an informal agreement between two people who are already onto the next thing.

Sprint 7: a second developer joins the story. He hasn't read the Slack thread. He implements the Excel export with a different data structure than the first developer, who has the CSV done. Code review surfaces it. Small fix, the team figures. Two hours.

Sprint 8: user acceptance test. The stakeholder looks at the feature. Then: "That's not what we meant. We don't export transaction data - only activity logs. Transaction data is confidential. It can't go into an Excel file."

Rebuild. Not a fix - a rebuild. Because the assumption the entire feature was built on was never validated. Because not a single test had ever questioned it. The actual requirement - what exactly should be exported, for whom, under what constraints - was never established: not in refinement, not in sprint planning, not in that standup in sprint 4.

The problem starts early. The cost arrives late. In between: the illusion that everything is on track.

Why sprint 8 costs more than sprint 1

Here's the question the sprint timeline raises: why does this mistake cost so much more to fix in sprint 8 than it would have in sprint 1?

Not because the fix itself is harder. The sentence "activity logs only, not transaction data" would have cost fifteen minutes of clarification in sprint 1. One precise question, one clear answer. In sprint 8, it costs a rebuild.

Because a complete feature was built on a wrong assumption. Everything built on top of it - implementation, tests, code reviews, integration - now rests on something that was never true. All of it needs to be revisited. And then there's the stakeholder's trust, which now carries a dent that nobody will name explicitly but that the next project will feel.

Barry Boehm documented this in 1981: the later in the development cycle you discover a problem, the more it costs to fix. For decades that idea was treated as something close to physical law - the kind of claim you don't argue with in a software engineering context. Later research complicated it. Some analyses of agile projects found no consistent delay effect at all; the relationship between when a problem is discovered and what it costs to fix is messier in practice than Boehm's original curve implies. But in a situation like this one, where a wrong assumption has been built into an entire feature, the direction is clear: the cost compounds with every layer added on top of it. I'm not going to cite specific percentages; the sprint timeline above makes the argument more honestly than any statistic.

The wrong diagnosis

Back to the retrospective.

The team doesn't feel like it cut a corner. It brought a normal story into a normal refinement. It trusted the process: the user story format, the refinement meeting, the assumption that "clear enough for now" is sufficient. No negligence. Just one question that wasn't asked.

The retrospective diagnosis, "we need to communicate better," isn't completely wrong. The team did miscommunicate. Developer A and developer B built different versions of the feature. The PO hadn't made clear what he meant. All of that is real. But if you improve the communication, this exact problem runs again in sprint 12. Different story, same cost.

Because the communication fix doesn't address what generated the communication problem in the first place.

The miscommunication between developer A and developer B wasn't a cause. It was a symptom. It happened because two people were working from different assumptions about what the feature was. Those assumptions diverged because nobody had ever made the actual requirement explicit. The causal chain doesn't start in the Slack thread from sprint 4. It starts in the refinement meeting from sprint 1, where nobody asked: which data, for whom, under what constraints?

I didn't correct the team in that retrospective. I didn't know better myself. I wrote "improve communication" in the notes. In sprint 12, the same sentence was on the board again.

What this means for your team

That leaves something unresolved: what could have been different in sprint 1, and why isn't it, in most teams?

This lesson doesn't answer that yet. It answers this: why "communication problem" addresses the symptom, not the cause. And why that distinction matters, not as theoretical precision, but as a consequence you pay for in sprint 8.

Requirements work happens in your team. It's in every refinement meeting, every sprint planning session, every Slack thread that's really a clarification conversation in disguise. Someone writes the story. Someone decides it's "clear enough." Nobody writes acceptance criteria. These are requirements decisions, whether the team calls them that or not. The question isn't whether they get made. It's whether anyone is making them on purpose.