I love to write. This blog, which I've been adding to since the early 2000s, is proof of that. Yet, I’m often amazed that we can communicate meaning through writing at all!
Writing isn’t always the best way to convey complex or rapidly changing information. In agile projects, writing typically works best as a way to prompt a conversation or document one. (That’s why user stories start as placeholders for conversations, not comprehensive requirements.)
To show just how unreliable words can be, I’d like to share two stories—one about the ambiguity inherent in English, and the other about how writing can be accurate yet unhelpful.
The Hotel That Was "Booked"
A few weeks ago I was traveling. I sent my executive assistant an email that said, "Please book the Hyatt in Denver for July 31-August 2."
Later that day, she sent back and email that said, "The hotel is booked."
With that crossed off my mental to-do list I moved on.
A few days later, I received a follow-up email from my assistant: "Did you want me to find a different hotel in Denver or do you no longer need a room?"
I was baffled. Didn’t she already tell me that the hotel was booked? Why was she now asking about finding a different place?
After a few more exchanges, I finally understood. When she said, "The hotel is booked," she didn’t mean, "I’ve completed the task." She meant, "The hotel is fully booked and has no availability."
What's interesting is to look back over the communication. Nothing is wrong with what either of us typed into our emails. We had each interpreted the same phrase entirely differently because we approached it from different contexts.
Accurate Doesn't Mean Understood
Here's a second example of how easy it is to miscommunicate.
While leading private agile team training in London, I decided to learn the rules of cricket—a notoriously complex game for the uninitiated.
I mentioned to my class, and one of the participants ishared instructions marketed as "Cricket Rules for Foreigners" in the UK:
"You have two sides, one out in the field and one in. Each man that's in the side that's in goes out, and when he's out he comes in and the next man goes in until he's out.
"When they are all out, the side that's out comes in and the side that's been in goes out and tries to get those coming in, out.
"Sometimes you get men still in and not out. When a man goes out to go in, the men who are out try to get him out, and when he is out he goes in and the next man in goes out and goes in.
"There are two men called umpires who stay all out all the time and they decide when the men who are in are out. When both sides have been in and all the men have been out, and both sides have been out twice after all the men have been in, including those who are not out, that is the end of the game!"
These rules are intentionally convoluted. Despite being accurate (presumably), they offer little practical understanding of how to play cricket.
What strikes me is how similar these rules are to many requirements documents. They might be technically correct and clear to those who already know the context, but they fail to truly convey understanding to new readers.
Clarity Is a Two-Way Street
Both stories illustrate a fundamental truth: clarity in writing doesn’t just depend on the author’s intent. It also hinges on the reader’s interpretation. Even when words are accurate or seemingly straightforward, they can still fall short if the context isn’t shared or understood.
In agile practices and beyond, it’s essential to recognize that clear communication is a two-way street. Writing can document, prompt, or memorialize conversations, but it rarely captures the full context. That’s why it’s so important to follow up, ask questions, and clarify intentions. Even the clearest writing isn’t immune to misunderstanding.
Last update: May 13th, 2025
