CONTENT IN SPRINTS

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

By: It is reproduced on page 67 of John Mueller: Astaire Dancing - The Musical Films of Fred Astaire, Knopf 1985, ISBN 0394516540.

"After all,
Ginger Rogers did everything that
Fred Astaire did.
She just did it backwards and in high heels.”

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

Holding successful content development sprints requires a large measure of planning. Although there’s no single formula that is perfect for every community, the more sprints held the greater your experience will be and you'll learn what works best for your team.

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.

1. Have an agenda. Do not walk into a sprint with no idea of what you'll be working on. Talk to fellow contributors and decide what needs to be worked on. Remember, even people who aren't able to attend can help craft an agenda for the sprint. Although having an agenda is important. Knowing what problems you're trying to solve and which parts of your documentation you're trying to improve is helpful. In fact, this can often affect who you most want to attend. But sprints have a way of bringing out new ideas. Don't be afraid to follow them just because they're not on the agenda.
2. Make sure everybody is prepared. One of the fastest ways to derail a sprint is to spend the whole time getting people ready to contribute. If people need to have specific software installed, or need to be familiar with certain technologies or processes, let everybody know beforehand.
3. Focus on planning. Collaborative planning sessions are a better use of face time, for two reasons. First, writing is easier to do alone than planning. People can write well when they go to their work area, but they won't plan as well as they could have together during the sprint. Intense writing sessions are good for virtual sprints, where people don't meet face to face. But when you're sitting in the same room as each other, it's much easier to find problems and figure out solutions. Second, planning sessions build better communities, because they tend to be more interactive than writing sessions. Successful sprints build community as well as create good documentation, because your community is the key to your success after the completion of the project.
   

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:

• Openness
• Courage
• Respect
• Focus
• Commitment

They help drive the behaviors in the group. Give sprint team members what they need and trust them with the delivery and getting the job done.

BLOG HOME PAGE