Documentation in Agile

Documentation Process in Agile

-Sharada

This article provides a time-tested documentation process that you can follow in agile. Are you a technical writer working in an agile environment? Then read on.

Working in agile brings an excellent opportunity for writers to contribute towards user experience as we are involved right from the initial stages.

Are you wondering how that is possible? As a writer, you are the first end-user of the application and better positioned to understand the user’s needs. When the cross functional teams read the requirements to understand the functionality, you can voice your suggestions towards usability improvements, meaningful UI labels, and error/warning messages. Since it is the initial stage of the process, your inputs will get considered.

process
 At a high level, our documentation process in agile involved the following phases:
  • Release Planning: In this phase, the Leads analyzed the tickets and created high-level estimates before assigning tickets to the team. Writers created task tickets in the Ticket Tracking System (Jira/Trac).
  • Research and Analysis: We decided on the content development approach and gathered information based on SRS calls and clarification/discussion calls. During these meetings, we also suggested UI improvements. We dived deep into the new feature to find out its working and business relevance. After gathering information, we performed user and task analysis for the new feature and created a high-level TOC.
  • Develop Content: We followed structured authoring and used Information Mapping to categorize the information into concepts, tasks, processes, etc. We also added graphics, flow diagrams to improve information presentation.
  • Verify Content: It is always a best practice to proofread content. We maintained a comprehensive writer’s checklist, which helped us to correct language and grammar errors. By this phase, the new feature was available in the test application instance. We tested content flow in the application, made corrections, and helped identify bugs in the application. 😉
  • Review: Getting the content reviewed by DEV/QA/PO (Product Owners) was important to us. As a process, the cross-functional teams expected the content during testing phase as they can verify the task flow against the application. We enabled the Collaborative Review option in PDF when sending the review content, which helped us receive simultaneous reviews from all the reviewers.
  • Revise Content: We incorporated the received comments. There can be situations in agile when a feature may be put on hold for future release. In such cases, version control helped us to maintain the removed content intact for future reuse.
  • Publish and Deliver: By now, the guide contained the finalized content from each writer. The guides were published and delivered based on the required delivery format (PDF, Web help). As part of the delivery task, the writers checked their content in the application online help before the sprint release.
This documentation process helped us to become an integral part of the R&D team, and thereby the agile process.

About the Author

Sharada has around 16 years of experience in Technical Writing and Content management. She is passionate about everything that involves technical documentation and excels in setting up and handling the end-to-end documentation process. Sharada loves to explore and learn new tools and technology that helps in simplifying the processes and documentation.

Sharada
2 Comments
  • Sunil Achary
    Posted at 15:27h, 22 November Reply

    Great outlining! Thank you, Sharada!

    • Sharada
      Posted at 12:26h, 23 November Reply

      Thanks Sunil 🙂

Feel like talking? Share your comment...

%d bloggers like this: