Why Don’t We Use Written English to Communicate Requirements?

A base assumption of Agile is that understanding of requirements is best achieved by:

1. Going to the “gemba”: In other words, actually seeing what people are doing
2. Talking about the need: In other words, asking questions and working through examples and assumptions
3. Getting everyone involved right at the beginning - product management, architects, testers, developers, and designers.

In particular, we try to avoid using “written” English to communicate requirements, because written English is open to different interpretations. Consider the sentence “Mary had a little lamb” and think about all the meanings this could have based on where you put the emphasis on the sentence:

• Mary had a little lamb - it was Mary's lamb, not John's
• Mary had a little lamb - she doesn't have it any longer
• Mary had a little lamb - she only had one lamb; other people had more
• Mary had a little lamb - it really was surprisingly small
• Mary had a little lamb - she didn't have the curried chicken like everyone else

You can see a shift in your emphasis while reading will potentially change the whole meaning of the sentence. Further, more words will often add to the problem.

And finally traditionally there is usually a series of documents that are used to produce different levels of documentation before the Team gets to work on them. Requirement documents lead to design documents and detailed design documents, which are then reinterpreted into testing documents and so on. Now we are compounding misunderstanding on misunderstanding. Is it any surprise that we might end up producing something that has no use to the person who asked for the capability?