Channels ▼


Agile Documentation Strategies

Documentation Alternatives

Agilists have rediscovered the concept of literate programming, of writing high-quality, easy-to-understand source code that contains embedded documentation. Furthermore, teams that take a behavior-driven design (BDD) approach consider their test suites to be executable, detailed documentation. Agile acceptance test suites forms a significant portion of the requirements documentation and developer test suites the design documentation. We follow AM's Single Source Information practice by having our tests do double-duty as specifications and therefore we require significantly less external documentation.

The "documentation is in the source code" philosophy covers the vast majority of technical documentation, but system overviews will still be required as will documentation for non-development staff. Andreas Rueping's book Agile Documentation: A Pattern Guide to Producing Lightweight Documents for Software Projects (John Wiley and Sons, 2003) defines a wonderful pattern language for improving the efforts of technical writers. Good documentation is concise—it overviews critical information such as design decisions and typically provides visual "roadmaps" showing the high-level relationships between things. Agilists focus on this style of documentation, and only write detailed documentation when it is needed and no better alternative exists.

Agile software developers travel as light as we possibly can, creating just enough documentation for the situation at hand in a just-in-time (JIT) manner. We believe that the benefit of having documentation must be greater than its total cost of ownership (TCO), that our stakeholders should decide whether to invest their money in it, and that we should strive to maximize the return on investment (ROI). Agilists are really smart about the way we write system, user, operations, and support documentation and as a result we tend to write significantly less documentation than our traditionalist colleagues. If you're interested in learning more about agile strategies for writing documentation, I highly suggest

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.