The last  couple of posts seem to state the obvious. They are , basically, variations of know your reader/customer. So, how hard could it be?

In my experience, there’s never time to do all of what is suggested. As a professional writer, the “topics-to-write” list has always been longer than the time available to write them—often by an order of magnitude.

Exactly the situation Agile was designed for.

I would think that writers would flock to Agile, if it’ll solve the problem of “so many docs, yet so little time.” And, they might, if given the chance.

Yet, in an unscientific study of documentation planning methodologies, they all look like they are based on a plan-driven (a.k.a. waterfall) project management model:

Plan, Write, Revise, Edit, Publish

…as though publish was something final. In Agile documentation, that might describe the process to publish a single topic, but it doesn’t scale up. If we call this sequence write-a-topic, in the larger scale, the documentation process looks more like:

Plan, Write-a-topic, Review, Repeat

Stopping every so often to step back and look at the view (i.e. take care of more strategic planning).

What works for me

I try to organize my documentation as much like the software development process as possible, but it took some de-programming to break the waterfall method into which I’d been indoctrinated.

It works best when I can define my documentation projects as epics, sprints, stories.

An epic is a large-scale project or functionality that spans multiple sprints and consists of many stories. For example, produce the documentation for a new feature. While the developers design the feature, I’m working with them to design the documentation—keeping the Agile methodology in mind. I  won’t be able to write it all at once, so I work with the product owner and the development team to figure out what functionality will be available when (in sequence, if not by date), what topics the customer will need and in what order (they can’t read it all at once anymore than I can write it all at once).

With that information, I define the stories and prioritize them with the product owner such that if I have to stop at any point along the way (e.g. to start on the next project), I’ll know that the most valuable topics have been written and the rest can wait (or they really weren’t as valuable or important as I thought they were).

The sprint planning and reviews keep the priorities in focus, but that often means that the epics are not done linearly. One documentation epic was about 2 months of work, but took 4-5 months to complete because of intervening priorities. Fortunately, I designed the content such that it was always publishable (shippable, in Agile terms) and the overall content set just kept getting better as I wrote it. Eventually, it was finished—as was all the intervening, higher-value content.

As Hannibal of the A-Team would say, “I love it when a plan comes together.”