Verbal Communication

Humans used to have such a marvelous oral tradition; myths and history were passed orally from one generation to the next. Until an Athenian ruler started writing them down Homer's The Iliad so that it would not be forgotten, stories like Homer's were told, not read. Our memories must have been a lot better back then and must have started to fade sometime in the 1970s because by then we could no longer remember even short statements like "The system shall prompt the user for a login name and password". So, we started writing them down.

And that's where we started to go wrong.

This is an excerpt from Mike Cohn's "User Stories Applied", which I encourage you to read.

What's wrong with written requirements? Actually they have advantages as well (traceability is an example), but they are based on a flawed assumption: they capture every detail of what must be developed. This is practically impossible, with the only exception of very trivial systems. Nevertheless, we do want to write something down, at least to be sure not to forget important things. So what do we have to write down?

User stories are very useful for many reasons, but one of them is that they favour high-bandwith face-to-face communication; actually stories are reminders for conversation. This calls for (I'd like to say force but it would be too optimistic) the customer and the team to interact frequently, thus leading to a product that is just what the customer wants instead of - at best - what is captured on a ton of paper that nobody reads.

This might not be true for every domain; some specific software would probabily require a very complete and detailed document, but this does not apply to anything I've had to develop so far (but I wouldn't be able to say anything about software for pacemakers). Yet, I think any written documentation is not complete unless it also describes how to test a feature. That is definitely what I'd like to have, rather than a series of "the system shall...". Oh forgive me, it is "the System shall...", capital S, we don't want to underestimate the beauty and the power of our product (which by the way does not yet exist if not in our dreams of glory).

Is time spent on requirements completely wasted, then? I think it is not. Requirements do not come out of thin air, so at least all the conversations held in requirements workshops can help the developers (but most of all the customers) to clarify what the business rules and information flows really are and what the system will really need to do in order to support them.

And this only emerges through verbal communication.