When creating content, you need a solid process and schedule. A well-thought-out, solid production process reduces churn, ensures consistency, and improves quality. Part of your content production process should include reviews, both for copyediting and technical accuracy. In an agile environment, different team members are required for each kind of review. To get timely edits and produce high-quality content, plan to include those reviews in the appropriate sprints, and make those team members aware you’ll need some of their time.
Pitfalls of the Traditional Review Cycle
When my team used the waterfall process, we used a review cycle that included three drafts of each content deliverable: a first draft, an approval draft, and a quality edit draft. The first draft and quality edit draft were internal to Information Development. All of these reviews happened toward the end of a software release cycle, and were not reviewed by anyone outside the Information Development team until the project was feature complete. So, all features were documented in one fell swoop.
Unfortunately, the time when we sent out our approval draft for review by other functional areas such as QE and Development often coincided with their busiest times of the release cycle–testing the product and fixing bugs. As a result, we received very threadbare comments on the documentation, if any at all. Needless to say, these reviews rarely improved the technical accuracy or clarity of our content.
Agile Review Cycle
With agile development, we now write documentation for a feature during the sprint in which it is developed and tested. On more mature products, we no longer send out the entire book as a first draft for ID review. Each time a feature is documented, that documentation must be reviewed by the ID lead and by QE for technical accuracy before the project team can close the user story. We consider this in-sprint review to be the first draft. Including the documentation of the user story as part of the “done” criteria not only solidifies ID’s role as an equal member of the team, it increases the amount of potentially shippable product at the end of each sprint.
We still send out approval drafts, but for most reviewers, at that point it is simply a chance for them to see the book in its entirety, since they have reviewed all the new and updated parts of the book previously. This review allows them to see all the individual pieces they previously reviewed in the overall context and workflow of the book, video, or help file they are reviewing.
Additionally, where the project team uses automated testing for the product, this review cycle reduces the amount of testing done near the end of a project, and frees up some of the testers’ time to review documentation and step through procedures to ensure their accuracy.
We have found the benefits to this approach include:
- QE and Development no longer have to review an entire book (or more) during one of the busiest times of the release cycle.
- Info Dev gets more thorough reviews since QE and Dev have more time during each sprint to review pieces of the documentation.
- More thorough reviews result in more technically accurate documentation and therefore higher-quality content.
- The writer’s capacity needed for an approval draft is reduced because most of the work has already been done in previous sprints. Therefore, if you manage multiple books on multiple products, you and your writers take a much smaller hit all on your time.
- Since you are likely moving writers around on a sprint-by-sprint basis, if you need to bring someone in to work just on the approval draft, they have a more complete document with which to work. This review approach reduces the amount of time needed to train them to pick up the work, get up to speed, and get moving with the work.
Adding Review Time to Sprint Tasks
While specific features get documented as part of the user story in each sprint, your team often writes content and perform other content-related tasks that are not related to a specific user story. To keep things moving, you should notify team members from whom you need reviews that you will need some of their time during the sprint to review these other content tasks. These items could include reorganization of a book, creation of a new video, help restructuring, etc.
To ensure this time request isn’t overlooked, you can create a user story for other content, and include tasks for your work for each of these items. Also, include time for each reviewer needed to read and edit these items, so they can count this time against their capacity for the sprint. This discussion will take place in your team’s sprint planning meeting.
Conclusion
Fitting your content reviews into the sprints themselves is beneficial for you, the writer, because it equalizes your work with the development and testing of a feature in a sprint. Using this process is beneficial for your team because it contributes to the whole team approach. It reinforces the concept of agile teams, where all team members work together to complete sprint work, rather than individual functional areas working separately. Finally, this process is beneficial for your customers, because it ensures higher-quality and more technically accurate content for them to use.
