Documentation in Agile Projects

There is a popular misconception that agile projects do not need documentation. But in my experience of product development, I find that documentation is an integral part of the agile teams and the workload on technical writers is actually higher in agile projects than in waterfall projects.

There are two main areas where documentation plays a very important role in agile projects:

1. Backlog list documentation

2. Product documentation in every iteration.

Backlog list documentation

The product owner is responsible for the backlog list. As the backlog list is a documented list of technical requirements, which must be refined to become a techncial functional specification document at the very beginning of the project iteration. I.e., the backlog list item must be developed into the requirement spec before the iteration for that feature can start. It is OK to have a bullet point or a brief description of each requirement in the backlog list at the project planning & project kick off stage, but as the project teams start working on a particular requirement, it bocome necessary to have a detailed product requirement specifications in order to execute faster and develop a superior product.

The product owner is responsible for creating this document and providing it to the project teams on the start date of that iteration. The more detailed the requrement specifications, the better.

Product Documentation during the Iteration

As the iteration starts off, the enginners refer the functional spec, and start their development. During the iteration, the engineers will have to document the implementation details of that feature - this becomes the input to Tech Pubs team or product documentation team to develop the product document the functional behavior of the product.

The documentation and engineers colloborate to finalize the functional specification document before the end of each iteration. At the end of the project, the product documentation will be complete and ready to be published.

A major reason to documenting during the iteration stems from the very nature of agile methodology. As the project teams can change during the project and the members who participated in one iteration may not be involved in the next iteration, there is a need to capture the implementaion details into the functional spec during the interation itself.

In large complex projects that use specialists - who will be used in specific iterations, and after their work is completed, they move out to different projects. In such cases - there is a need to capture the implementaion details into the functional spec during the interation itself.

Role of Product Manager in documentation

Product manager or Product owner must review all the documentation at the end of each iteration and sign it off and send it for review to other stake holders. At the end of the project, the comments of other stake holders can be incoporated before publishing the documents as part of product release.

Product Manager and the Technical Publication team are the joint owners of product documentation. With agile projects - where requirements are changing there is extra demands on documentation - as they have to keep up with changing requirements.

Product owner or product manager must drive the documentation process for the project. The scrum master ensures that the documentation process is followed & documentation is completed in the iteration.

Option of documenting everything at the end of the project

If the project is not very large and is planned to end within 3-4 months, then documentation can be done during the last iteration often called as "Release Sprint". Release Sprint is done so that the remaining work such as system integration, environment testing, system validation etc, are completed. Though in theory of agile methodology - every sprint is supposed to end with a shippable product, a Release sprint will be needed because not all the activities needed for an actual product release will be done for each sprint.

All documentation can be done in the release sprint provided all the members of the project team does not change during the course of the project. Based on my experience, documenting at the end of the project - ie., in release sprint is preferred for small projects - typically incremental releases, patch releases etc.

The product owner must maintain the list of activites that needs to be done in the release sprint - typically, this would be performance, regression, system stability, security & integration testing activities and documentation related activities.

Closing Thoughts

There is a general preception that agile projects can be done with less documentation, but in reality the opposite is true. There is a greated rigor for documentation in agile projects, and for product development projects, documentation is part of every sprint. Agile methodology places greater stress on documentation and documentation resources needs to be committed all through the project.

Doing all the documentation during the release sprint is not a good option therefore it must be used judiciously only in small projects.