A minimalist editorial illustration showing a user story card on one side and a destination flag on the other, separated by a bridge with one missing section. The missing plank is labelled "So that...", symbolising the missing connection between documentation and shared understanding. A small compass icon and the title "What AI Doesn't Change" appear above the scene.

The Missing 'So That': A Case Study in Distance

Generative AI can produce a user story in seconds — actor, action, structure, even a plausible “so that” clause if you ask for one. It can draft acceptance criteria too. None of that touches the part of the process that was always the hard part.

The Three Cs — Card, Conversation, Confirmation — have described user stories since the practice was first named, and the framework still holds up well against Gen AI tooling. The Card is the artefact: a short written story, deliberately incomplete and ambiguous, meant to start a conversation rather than settle one. Gen AI is genuinely capable at producing that artefact. The Conversation is what happens next, as the story moves through the team’s flow — the back-and-forth between developers and the Product Owner that fills in what the Card left out, often more than once as the work takes shape. Confirmation is the check that closes the loop: another conversation, at the sprint review or ideally before, where the team and the Product Owner agree out loud that what got built is what was meant. None of that is a writing task. All of it depends on shared understanding, and shared understanding is the result of honest human communication.

📥 Want a practical framework for this?

My free guide — Insights to Improvement — walks through how to identify quality gaps and build the team habits that close them. Used by agile teams in the UK and LATAM.

Download it free →

I worked with a seven-person B2B web development team where this gap had nothing to do with AI tooling — the pattern predates it by years. The team had been through enough turnover that most of them were following practices they’d inherited rather than chosen. Stories were written once and left in the backlog. The “so that” clause — the part of the story that states the intention behind the request, not just the request itself — had quietly stopped being written. Nobody had decided to drop it. It just wasn’t there anymore, the way inherited habits often lose their reasoning along the way.

The visible symptom was a familiar one: a persistent feeling among developers that they were “getting it wrong,” alongside real pressure to nail the specification precisely — pressure that pushed all the attention onto the Card, and none onto the other two Cs. The less visible symptom took longer to show up: planning sessions kept getting longer, because without a stated intention behind each story, every decision had to be re-litigated from scratch instead of reasoned from a shared “why.”

What had actually happened was distance. The Product Owner was no longer available full-time, and as that distance grew, the team lost the informal, in-the-room conversation that used to compensate for a thin Card. Nobody had named that distance as the problem. “The way we’ve always done this” carried more weight than the question of whether it still made sense. Naming that distance explicitly was what broke the “we’ve always done it this way” resistance; once the team could see why the practice existed, reintroducing it stopped being a process mandate and became an obvious fix. I worked separately with the Product Owner too, on trusting the team enough to let go of specifying everything up front — helped along by a simple reframe: the cost of a wrong decision made locally is usually lower than the cost of a feature delivered late.

None of this required AI to happen, and none of it will be fixed by AI either. A generated Card can look complete and still carry none of the intention a real Conversation would have surfaced. The discipline that catches that gap — writing the “so that,” closing the distance, having the Confirmation out loud — is the same one it’s always been. (For a related but separate concern — the shape and quality of the stories themselves — I’ve written previously about applying the criteria to diagnose stalled sprints.)

If this resonated, the next step is free.

A practical guide on turning team improvement into a repeatable system — the same approach I use with clients. No pitch, just the framework.

Download: Insights to Improvement →

If your team’s stories look complete but the decisions still keep coming back to one person, let’s look at where the distance crept in. Reach out today, and we’ll start with what your last few planning sessions actually needed to resolve


Discover more from The Software Coach

Subscribe to get the latest posts sent to your email.

Leave a Comment

Your email address will not be published. Required fields are marked *