Thinking about documentation

In working these days in a presentation I'll be doing with a peer on "Requirements in eXtreme Programming". I'm taking a course about Requirements Engineering with a strong focus in RUPs way of doing requirements, so guess it'll be important to address the topic of why XP does so little documentation.

In the Art of Agile Development, James Shore explains the 3 types of documentation:
- Work In Progress Documentation: helps you to get your job done.
- Product Documentation: documents that provide business value
- Handoff Documentation: documents for handing off the project to a new team

Requirements documents and design documents are usually just work-in-progress documentation. The real need is how can we communicate while we develop software. XP emphasizes a whole team (customer, programmer, testers) that sits together, communicates face to face and shares a common language (ubiquitous language).

I agree completely in that oral communication is much more effective than just receiving a document (use case or any other) with a task that says "Program it". What if instead of giving documents to our programmers we give them a brief statement of what need to be done and then they have the chance to get the requirements directly with the customer? That is the idea of using user stories. They are work-in-progress artifacts. They are not little requirements documents, but they replace them with a cool combination:

On Site Customer + User Stories + Common Domain Language + Iterative Development (program byte-sized requirements) + Automated Tests (unit and customer tests)

I thought that User stories were just a lazy way of not writing use cases (or SRSs) but actually they are a smart way of remembering that we need to communicate with the customer. XP practices really support each other, so I think that before saying "XP doesn't work for me cause it does so little documentation", we should take a look at how all practices fit together.

A little conclusion: XP supports written communication with other practices that are far more effective than just written documents. (check page 195 inThe Art of Agile Development).

In the next days, I'll be googling, thinking and writing about where do use cases, as a technique, fit in agile. Hope you'll come back and read my findings and opinions!