As I discussed in the Whole Team Approach Part 1 and Part 2 articles earlier this year, writers should include tasks for their work in the same user stories that include Development and QE tasks. This approach ensures that each user story is truly done at the end of a sprint, and helps agile team members from all functional areas work together to build a “potentially shippable” product in each sprint.
Despite the obvious benefits of the whole team approach, if you’re not careful, the agile process structure can dictate what kind of content you’re writing. Since teams often fall into the trap of defining user stories as features, your content can fall into the same trap—you end up documenting the product, rather than how to solve your users’ problems with the product. This article offers some considerations for creating task-focused content —keeping your content focused on what users need to do their jobs.
Work and Deliverables to Consider
Creating content for your users involves much more than simply writing documentation. It requires thought, planning, information architecture skills, virtual machine setup, subject matter expert interviews, an eye for usability, and more. When starting a new agile project, you must consider all of these items during release planning and determine what you need to do and what you plan to deliver in the course of that release cycle. Continuing to create “doc plans” that are tailored to your particular team’s work styles and deliverables is useful. For some great discussion around how these are beneficial, see the Agile Technical Writers LinkedIn group discussion.
While the agile process allows for quick changes and sprint-by-sprint planning, if you don’t plan on a larger scale, it can be easy to forget about the “infrastructure-type” tasks you must do during a release cycle. For example, tasks associated with reorganizing a legacy documentation set do not naturally fall into user stories designed around new features. Writing content targeted toward solving user pain points requires concepts, examples, and best practices information that don’t easily fit the user story model.
Usability testing, another essential part of a project, goes hand in hand with targeted content. Improving the product through user interface reviews and iterative usability testing helps the user experience and reduces the amount of documentation needed to explain complex or non-intuitive interfaces. You can certainly include usability testing tasks in a user story for a feature, but what about the usability of the interaction between that feature and another feature?
The same principles apply for video content as well. Occasionally, you might need to document a particularly complex procedure or complicated idea in a video. While some of these planned videos might fit into an existing user story, how do you fit the work associated with these larger, overarching concepts into an agile framework?
Content Overrides Process
Working in an agile environment does not mean that team members must adhere to a rigid process with no deviations. The very term “agile” implies a fluidity to the process that the team can use to get their work done in the most effective way for that team. The most important thing to remember is that your content overrides your process. Content is #1, and your process must enable you to create the desired content in the desired formats effectively and efficiently.
Take advantage of some extra time in early sprints in the release cycle to do setup work. Often, requirements are still being clarified and Development is doing research during these early sprints, so this time is perfect to work on documentation bugs, help system setup, or content reorganizations. Since it’s likely that there are no team user stories for this work in the backlog, use Information Development-only user stories to track this work in the sprints.
While you can’t do usability testing too early in the release cycle (because you need prototypes or code to test), try to start this testing as soon as you can in the cycle so you have time to apply feedback from the tests and hopefully run them again. Again, create user stories specifically for this testing if it doesn’t match up with your existing user stories.
Finally, using the whole team approach for both content development and usability testing reinforces the idea that shipping a high-quality product is the whole team’s responsibility. Agile does not require that you only have user stories in which Development does the coding, QE does the testing, and ID does the content development and/or usability testing. If someone on the team has some bandwidth and can help out with content development, let them! Track the work in the sprint, and don’t let functional roles dictate who does what. The team is a collective unit working together to deliver the appropriate product and content.
Conclusion
There’s no doubt that working in an agile environment provides many benefits to information developers. The increased communication, equality among other functional areas, and numerous feedback points help boost writers’ morale and increase content quality. But remember to let the process work for you and not against you. Continue to focus your content, include important usability work, and work with your team, using that agility to your team’s benefit.
Useful Links
“Writing End-User Documentation in an Agile Development Environment,” Tana Berry and Anne Gentle. http://justwriteclick.com/2007/07/02/writing-end-user-documentation-in-an-agile-development-environment/
