One of the biggest questions when bringing agile into the enterprise is “How do we document requirements”. There are stories and acceptance criteria, human-readable code and TDD test results, all of these things provide a hodge podge of documents that can be pulled together to represent a deep understanding of system behavior, and may be understood by a fairly intelligent, tech-savvy user. These solutions do not provide what we need.
Agile developers have come up with a lot of different solutions as a result. Sometimes it’s trying to find a prettier way to format or name tests, other times it means handing the project off to a technical writer once everything is said and done. Amongst the solutions I’ve seen are video tutorials, UML charts and extended Q&A sessions with stakeholders and potential users.
UML, videos, Q&A and sprawling explanations written by technical writers all suffer the same fundamental flaw. In any project that is under continuous development, meaning regular version updates coming with potentially major, or even work-flow altering, changes, the cost of maintaining documentation grows exponentially. What’s more, those documents, which the development team has committed to maintaining for the remainder of the product life cycle, have no intrinsic value outside of being documentation.
There is, I believe, a solution. This solution requires a complete retooling of the development process from the very beginning all the way through final UAT.