Our Technical Writing Process

We understand that an Agile team should be co-located, but we are also aware that frequently it is not possible. This is especially true for technical writers because many companies cannot afford to dedicate a technical writer to a single product. We start every project with a kick-off meeting to review the documentation scope, backlogs, release goals and create a communication plan. Then, we agree on the agile planning tool so that we can create our tasks and present the feature documentation at the end of the sprint.

Key Steps
• Define Goals and Objectives
• Create a Communication Plan

Once we agree on the communication plan, we’ll study your product backlog and we’ll conduct a full product audit to see what currently exists and how best to document the new requirements. Then we’ll document our tasks and get client sign-off. This ensures that we don’t forget stuff which can eat up our time during the hardening phase. We’ll also agree on the technical writing tools, source control, and documentation delivery mechanism.

Key Steps
• Complete Product Audit
• Define Technical Writing Tasks
• Access Documentation Delivery Mechanism

Our technical writers understand the users before they start creating documentation. We look at personas and understand their goals and the product usage pattern. Then, we mock up the structure (TOC) of each of the documents, clearly defining the topics and their information types. We love only three information types: Concept (overview information), Task (procedural information), and Reference (factual information). Once the structure of all the documents is approved, it’s time to get into sprints.

Key Steps
• Understand User Personas
• Create TOC
• Sprint Planning

We always create document templates using existing brand guidelines. We are minimalists and are aware that people don’t like to read long and boring user manuals. We ensure that our technical writing teams write in such a way that users can get to their information quickly and intuitively. Our technical writers love working with XML and Darwin Information Typing Architecture (DITA).

Key Steps
• Create Template
• Minimalism

Once we are part of the scrum teams, we attend sprint planning and daily scrum meetings. We understand the user stories and create documentation tasks. Then, we start authoring self-contained units of information about a specific topic. We always use a collaboration tool, such as Wiki or Microsoft OneNote to gather information from developers, testers, and product managers. Once we write the topics, we send them for technical reviews and fix the errors, if any. To ensure a productive relationship between dev teams and technical writers, we encourage clients to mark a user story as NOT DONE if the end-user documentation is not complete.

Key Steps
• Create a Development Environment
• Develop Site Templates
• Build CMS
• Upload Content

We conduct rigorous editorial reviews to confirm that technical writing is as per the standard rules of English. We ensure that it follows the global English guidelines. We also check whether screenshots, flow charts, and conceptual diagrams meet the graphic guidelines. Then we fix any grammatical or style errors we find, including optimizing graphics, checking for broken links and making sure everything looks right. At the sprint review meeting, we demo the documentation and once the product owner accepts the documentation, we publish it on the documentation portal or the documentation branch.

Key Steps
• Review Grammar and Style
• Review Graphics
• Documentation Demo
• Publish Documents