This article was coauthored by Padma Swaroop Mandapaka.
In any product development, it is often perceived that documentation plays second fiddle to development in Agile. In reality, this is an understatement, as without documentation it would be very tough for any product to be successful. In fact, in today’s world, both these domains play a key role in the success of a product.
So, what exactly is documentation? Documentation can be described as a process that makes any product live. In other words, one could say: Documentation brings the product to life. And we emphasize that here we are not discussing documentation needed by the team to build
the product but rather the documentation that the customer needs in order to use
the completed product properly and safely. In a sense, this documentation is a part of the product, as it is part of what the end user receives.
Now, at what stage does this type of documentation come into the picture in a typical Agile product? After any new feature is developed/enhanced and passes the Quality Assurance validation, it is time to document the new feature or enhancement of an existing feature.
The typical deliverables of documentation of any product include a getting-started guide, an installation checklist, an installation and configuration guide, and an administrator’s guide. As is the case with development, all documentation has to be thoroughly reviewed before it is made available for release along with its respective product.
Every fragment of the documentation must satisfy a constraint: the Definition of Done. Documentation is deemed to have met the DoD if it satisfies the following conditions:
- All the relevant documentation for a feature/enhancement is complete.
- It completes the technical review for that fragment.
- It completes the internal and peer reviews for that fragment.
A technical review is usually conducted by the developer or quality analysis team, and internal/peer reviews are usually done by the fellow documentation members.
On average, any single fragment of documentation would take somewhere between two to four days to undergo all the reviews. So in an ideal scenario, will a four-week development sprint accommodate all the documentation in the sprint, meeting the DoD? Unfortunately, the answer is no, in most cases.
s As the documentation comes into the picture after week one in to any development sprint, an ideal sprint will have around 78% of documentation covered. The remaining chunk of documentation is usually carried forward to be addressed in the next development sprint. One way to overcome this shortcoming is to complete the technical review of the documentation fragment in the current sprint, and conduct the internal and peer reviews in the following development sprint. In this way, one would not fail the development user stories.
At this stage, it is important for us to understand that the capacity/work done for the documentation team is considered by keeping in mind the product release date and not the individual sprint date.
In an Agile model, it is a common practice to hold a separate sprint for the documentation team. The documentation sprint will keep a track of all the user stories by all of the documentation team members. This is because, in most organizations, any single documentation member will handle more than one Scrum team. A separate documentation sprint will enable one to keep track of the entire work done by the documentation member for all the Scrum teams with which he or she is associated.
- Documentation of this sort used to have little importance in the overall development of a product.
- In Agile, documentation plays an equal role in the overall development of the product.