SCRUM AND AGILE SPRINTS
We’re all familiar with Scrum and Agile sprints for software development. This model of working in sprints has now also edged into content development cycles. A sprint—also known as an iteration—is a short period (ideally 2 to 4 weeks) in which the development team implements and delivers a discrete product increment, for example, a working milestone version.
Content developers can use Agile practices, such as Scrums and user stories to create a progressive canvas on which to develop customer-facing documentation, like user manuals or online help.
User documentation is as much a part of the product as source code. If a product has user documentation associated with it—a setup guide, user guide, administrator’s guide, or reference manual that aids the use of the product and its features—that documentation must be considered to be an integral part of the product itself, and must be delivered at the same time as the software components of the product.
TECH WRITERS MOVE LIKE GINGER ROGERS
Most companies using Agile and Scrum have found that separating documentation from development just doesn't work. Content developers as members of the software development team must be fully integrated and immersed in the process of creating and releasing the end product. The only way to deliver good customer-facing documentation under Agile and Scrum is to have content developers in the sprint team, working side-by-side with the other team members building the product. In that way, writers become less reliant on formal specifications like use cases. Ultimately, however, the composition of the sprint team reflects the nature of the product being delivered. If the product is purely internal and no user documentation is required, there is probably no need to have content developers in the sprint team.
In the world of sprints, content developers have to quickly come up to speed in their understanding of the software as it’s being developed. And, they’re usually under even tighter schedules since SME “stabilized” information shared with the writers usually comes late in the sprint. So keeping in step with engineering, while learning the product and capturing and developing the necessary product information for the user is no easy feat.
For content developers assigned to different sprint teams, on both legacy and new products, the key is organization and communication with the teams and product owners. Precise action plans and division of work into tight blocks of time or sprints are essential. Content developers need to understand at a high level the tasks that developers or product engineers need to complete in a sprint. And content developers need to communicate to these team members the work required of a writer.
Content developers are frequently required to deliver to the customer multiple large user manuals and other complex technical documents. These deliverables commonly require quality reviews and updating during each sprint cycle, depending on the stage of the software development cycle. In an Agile or Scrum environment, reviews for new features should be happening within the same sprint as the development and testing. All this is done with no slipped delivery deadlines allowed—of course.
Oh, and then there’s the added pressure of making the content accurate, clear, easy to use, and engaging—creating Ginger Rogers magic. Content developers must get it right (no missteps or floor flops), especially if the expectation is to sell and generate revenue from the product.
HOW TO MAKE IT WORK
A great number of potential sprints never happen because nobody pushed for them to happen. Although getting people to attend sprints is fairly easy to do, if your community members aren't used to attending sprints, you'll probably have to be a bit pushy to get them to commit to join.
Here are three useful sprint tips.
FIVE VALUES OF SPRINTS
To get low-touch, high-return in your content quality and accuracy, content development sprint teams need to rely on the 5 values of sprints in an Agile or Scrum environment: