Get certified - Transform your world of work today


Documentation in Agile

Tracking the work of documentation for the end user

13 July 2016

Ramesh Lakkaraju

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.
Note: 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.

To summarize:
  • 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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 2 (4 ratings)


Karl Barthel, CSM, 7/14/2016 10:20:07 AM
Sadly, Ramesh, your view is very short sighted. The industry standard for the length of a sprint is 2 weeks, not 4. If you feel that you couldn't complete the appropriate amount of documentation to accompany the feature in a sprint, you aren't splitting the feature(s) into small enough slices.
Ramesh Lakkaraju, CSM, 7/15/2016 6:31:36 AM
Thanks for your feedback. As you have mentioned 2 weeks is industry standard, can you please provide the reference for the same. Is it not that max can be the 4 weeks depending on work, team and organization?

Also, it is quite common to have last minute critical requirements from the development teams in big established product based companies with multiple teams on board requiring documentation changes.

Hence, it would be appropriate to separate the documentation sprint and the development sprints by a week.
Tim Baffa, CSM, 7/20/2016 4:25:12 PM
Ramesh, there is a sprint. That's all.

There is not a hardening sprint, although such a practice is unfortunately commonplace in companies that have yet to move to continuous integration and deployment, and do not have a robust Definition of Done.

There is no such thing as a development sprint. Nor is there a testing sprint, or a documentation sprint. That is simply perpetuating a waterfall practice under new labeling.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up