Sometimes, the Agile software development methodology seems like it could be renamed the “Fly by the Seat of Your Pants” methodology. But really, it means that you need a somewhat different set of project management skills for your documentation. I could certainly improve in these skills, but here are a few I rely on in an Agile environment.

Skill 1: Topic-Based Writing

Before I describe this one, I need to point out that yes, writing isn’t exactly planning; writing is what a technical writer does after planning. Writing is a rubber-meets-the-road activity.

True, but the project management applies in the way that you plan to write. I heard it said once that DITA is perfect for Agile environments because the way writers chunk information in that scheme allows that information to be dispensed from a single source into whatever output happens to be needed at a particular time. In short, it allows writers to quickly respond.

If I could substitute “topic-based writing” for “DITA” here, I would add that another great benefit is that writing in small topics allows you to keep pace with development and to release documentation in step with the application updates. Small topics give you less work to do in the iterations or sprints and enable you to mark your progress more regularly. So plan to write small in general and then adapt as needed.

Skill 2: Work Estimating

I have worked on projects where the program manager, the customer, and I agreed on certain deliverables at the beginning of the project; but over the course of the project, it became apparent that other documentation would be helpful, such as quick reference guides to fill a certain need.

One of the management skills that helps here is estimation. I have made it a practice (and I understand this is generally a good practice) to overestimate a bit on the number of hours I think I will need to complete the documentation for a software application. Then, if I encounter unforeseen complications, I have some extra time to deal with them. But if I complete most of my tasks with some room to spare, I have room later to meet some of those additional needs.

Skill 3: Translating User Stories to Documentation Topics

I’ve written about this one before in some suggestions for Agile technical communicators, but it’s a good one for this subject.

By the time I am asked to give an estimate, the Agile development project has a set of user stories that describe the general functionality that needs to be provided in the application. Many of them translate easily into task-based topics. For example, a user story entitled “Authorize users in the application” will probably mean users will need to know how to get access, to authorize other users, change permissions, or remove users.

Even though user stories (or use cases) start out very general, you can use them to plan out how you will structure the documentation and the approximate number of topics needed.

Skill 4: Matching the Deliverables with Needs

Taking things a step farther from planning doc topics from user stories, ask questions to know who the users are, how many user roles are involved, what their environment is like, and so on. You may have favorite deliverables, but knowing the audience (one of those tech comm statements to live by) will help you select deliverables from the start and be able to expect them throughout the project lifecycle rather than having to introduce something new and hoping you have the room in your schedule and budget for it.
Will you create online help, quick reference guides, release notes, video tutorials, all of it? Getting the facts about the audience first will help you plan your deliverables and minimize surprises.

Skill 5: Flexibility

Planning is largely about anticipation: trying to see what is going to happen and acting accordingly in order to meet it. But one of the synonyms of Agile is flexibility (or change, however you want to look at it). This is the main reason I feel sometimes that I’m being reactive more than proactive. I don’t mind responding to new requests; I would just feel more comfortable and organized if I had planned on them.

Since Agile allows for a flexible schedule and frequent contact with customers, scope creep is a danger. It takes some discipline to avoid scope creep by trading and swapping user stories in the schedule. If something is added, something else has to be taken away in order to keep the schedule and the scope intact.

The same principle applies in Agile documentation projects. If the customer or project team requests some new or expanded deliverable, some negotiation is probably in order. It’s nice to have a bit of padding in your estimates, but if things are running tight, understand and be ready to explain the risks of meeting the request.

As user stories are rearranged in the schedule, be prepared to move documentation tasks along with them. Have contingency plans in the event you become blocked on a task. And of course, don’t be surprised when you learn something has changed.

Wrap-up

After several years working on Agile projects, I’m still working on my Agile documentation project management skills, still trying to get it down to a science. If you have additional skills you rely on for Agile documentation project management, please share them.

Related entries (auto-generated):

Suggestions for Survival in an Agile Environment as a Technical Communicator

Release Scrums: An Important Resource for the Agile Technical Writer

Reviewing Projects and Deliverables as a User Education Team

Don’t Be Strangled by Strict Documentation Organization

An Interaction Designer Who Understands the Need for Documentation