Communication Friction: Are Your User Stories Growing?

User stories are stated as something simple. Just a few words in a Post-it note to start and guide a development task. They were never intended to act as requirements definition documents.

This article delves into a pattern I am seeing. Six months ago, your user stories fit on index cards. Today, they’re three-paragraph specifications with bullet-pointed acceptance criteria and mockups attached. There is a sense of progress in this: “We’re getting better at requirements engineering.” However, I find that most often than not, this growing length of user stories can be a sign that communication friction is accumulating, and you’re compensating by adding text.

Cards, Conversation, Confirmation

Ron Jeffries introduced the three Cs of user stories: Card, Conversation, Confirmation. The card is deliberately minimal because valuable information transfer happens in conversation, not documentation.

When you can walk to your product owner and ask: “what did you mean by this?” you need little written down. Synchronous conversation is high-bandwidth. You clarify ambiguity in seconds, explore edge cases interactively, and reach shared understanding through dialogue. Written text is low-bandwidth and high-latency by comparison.

Small cards work when communication friction is low.

What Compensation Looks Like

I recently worked with a team whose stories had grown from cards to multi-paragraph specifications over eighteen months. At some point, they’d introduced backlog grooming meetings—two hours, twice weekly—to handle the “requirements complexity.”

During grooming, developers asked for examples and clarification. Product owners provided detailed answers. Everything went into Jira. Stories grew to several paragraphs before development started. Stakeholders signed off, and developers began work.

Both sides were oblivious to losing the conversation.

Developers asked questions in ceremonial meetings rather than during development when the context was fresh. Stakeholders front-loaded details because they wouldn’t be available later. Nobody talked during actual development—when questions naturally arise and answers matter most.

Maybe they were getting better at requirements engineering. But most importantly, they were compensating for communication friction with documentation. And documentation can’t respond to questions you don’t know you have until you start building.

When Documentation Serves Conversation

Some friction must be accepted. I worked with another team facing geographical distance between development sites. The product owner couldn’t be constantly available – let alone to serve both time zones.

We focused documentation on conveying intentions—why the feature mattered, what problem it solved. Developers could make tactical decisions when the product owner was unavailable because they understood the intent.

This is appropriate: capturing context when conversation bandwidth is genuinely limited. The text serves conversation by enabling decisions during absence.

What’s inappropriate: using documentation as a contract because you’ve stopped trusting each other. Or adding text because your communication infrastructure has friction you’re not addressing.

What Your Growing Stories Tell You

Compare your user stories from a year ago to today’s stories for similar-complexity features. Did they grow?

That’s communication friction accumulating. Not because your product is more complex, but because:

• Your product owner’s availability decreased
• Your team became distributed
• Your stakeholder turnover increased
• Your trust eroded

The friction increased. You compensated by adding text. And now you’re moving more slowly while feeling more rigorous.

You can’t see your own friction accumulating. You feel like you need “more detail” because questions keep arising. Taking a step back can reveal this pattern: your stories are growing because your communication infrastructure is degrading.

When the only response to friction is “add more text,” you’re not solving the communication problem. You’re creating an illusion of clarity while making everything slower.

Next week: how to reduce friction instead of documenting around it.

---

While the principles discussed here are straightforward, their effective implementation often requires a nuanced understanding of your team’s specific friction sources and communication patterns. That’s where evidence-based coaching makes the difference, helping you identify where friction is accumulating and whether you’re managing it appropriately or just adding documentation that creates the illusion of clarity. Reach out today, and let’s talk about what your growing user stories are actually telling you.