What makes a doc plan Agile?

Does working in an Agile development environment change the documentation plan, or user information plan?

For many writers, the purpose of a doc plan is to inform the stakeholders what you (or your team) intends to deliver for docs for a particular product release and when you will meet key milestones.

Here’s an outline of a typical user information plan that includes signoffs from interested parties, with the goal being that you work with your team to agree to what information deliverables are necessary for a software release to be complete.

  1. List of deliverables
  2. Risks and dependencies
  3. New features
  4. Documentation milestones and deadlines
  5. Techpubs expectations and assumptions for meeting the deadlines

That outline was from an actual doc plan from about three years ago. It was feature-dependent and waterfall-driven.

In an Agile environment, the doc plan might be more minimalist, listing only:

  1. key players
  2. release theme and top features in the release
  3. dates

Then the real work of planning the details of what needs to be addressed in the doc happens during iteration planning. The detailed planning may not be written down in a doc plan, spending the time on writing the end-user doc instead.

I suppose the most Agile doc plan would be a simple verbal agreement to what will be in the doc each iteration.

If there’s a sliding scale, what is the least Agile doc plan? What is the most Agile doc plan?

4 Comments

  • August 4, 2007 - 5:58 pm | Permalink

    Interesting post. I added my thoughts on documenting in an Agile environment in my blog (http://talk.bmc.com/blogs/blog-marques/michele-marques/). If you don’t see the entry yet, check tomorrow.

    BTW, have you considered adding trackbacks to your blog?

  • August 6, 2007 - 11:08 am | Permalink

    Thanks for commenting – trackbacks are enabled so I’ll keep an eye out for your trackback. Just put the URL for the post itself in your trackbacks field. There’s no separate trackback URL with my blogging software (WordPress).

    You say that you “include updates to the doc plan in the schedule” so you’re planning doc details with each iteration. I think that’s an ideal middle ground, letting the writer use the doc plan for planning and organization purposes with each changing iteration.

    But do you run out of time for updates eventually? No one refers to doc plans after a release is out the door (other than to use it as a template for the next release), do they?

    I found it difficult to keep making changes to the doc plan while I was writing the end-user doc itself. As a planning tool, doc plans are useful, but only for a few iterations and only for the writers and maybe one or two other players it seems. I would go towards a lean doc plan that’s throwaway after a few iterations.

    Oh, and I have to laugh at myself while re-reading my post — apparently it’s more “Agile” to use lowercase for the initial word in a numbered list since I did that style for my second list. Ah, quick posting is fun. And you know, I’m not going to change it now. :)

  • August 9, 2007 - 12:07 pm | Permalink

    Hmmm…. I specified the URL of this post, but my blog entry didn’t get added here as a comment.

    Regarding updating my doc plan – I send an update out for each of the early iterations, when things are still in flux.

  • Gwendolyn
    January 3, 2012 - 12:59 pm | Permalink

    I appreciated the article “What makes a doc plan Agile”. The purpose of the doc plan has not changed in the last um-teen years: it is still to raise and solve questions on the who, what, why, when, and how of a documentation project. I find that the doc plan opens discussion with the InfoDev team and the other members of the development team (Developers, QA, CS, Project and Product Management). The details should be flushed out during iteration planning, but as much detail as possible should be outlined in the doc plan for scope capture. All-in-all, whether waterfall or Agile, the doc plan continues to define InfoDev scope, requirements and deliverables.

  • Leave a Reply