At a recent presentation one of the questions started something like this. “You used two words in that sentence that don’t normally go together, Agile and documentation.” This a common misconception, made more common by the fact that many people who want to practice Agile don’t want to document. But necessary documentation is a basic constraint of any project and needs to be considered in your definition of done. Of course, the documentation that is necessary is dependent on the project itself, with regulated projects needing more documentation than others.
You have to remember that documentation is a communications medium. Like every communications medium, you need to consider the message and its purpose to determine whether the medium is appropriate. The purpose of the documentation medium is to communicate into the future. You need to ask yourself, “What will people looking at this project in 3 months need to know and why?” Then you tell them now in a document.
Unfortunately, in many traditional development projects people document to protect themselves. When the customer and developer disagree on what the customer said he wanted, they turn to the signed requirements document to clarify what was actually said. What they often find is that the requirements document was ambiguous enough to support both answers. The document failed to achieve the goal because the goal was not one a document can easily meet.
The best way to avoid this problem is to reduce the time between the user telling you what he wants and you showing it to him. And when he tells you what he wants, don’t ask for requirements, ask for Acceptance Criteria. This is why Scrum likes to get the details at the beginning of the Sprint and show working software as soon as possible. With as little as two weeks between finding out exactly what the user wants and gaining acceptance from the user, you aren’t as likely to fight over what the user said. Additionally, you don’t have to wait until the software is fully working to show the user a screen or a functional demonstration. The sooner, the better, the less arguing.
But, for those things that need to be communicated into the future, including evidence for regulators, add the documentation to your definition of done, and provide your Story estimates accordingly. Since each documentation task is based on a small piece of the functionality, it won’t seem such a burden, and will be higher quality to boot.