RE: The Agile / Xtreme TW

Subject: RE: The Agile / Xtreme TW
From: Michael West <WestM -at- conwag -dot- com>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Fri, 13 Feb 2009 09:19:49 +1100

"Cynthia Tucker" wrote:

> I'm struck by the number of people who
> say that they have documentation
> STORIES as part of the iteration.
> At our small shop, we don't have
> documentation stories, we have
> documentation TASKs. As we task
> out the feature story, we add a
> task to document the feature.

"Documenting the feature" actually sucks as a task description. What does
it really mean?

If you capture the exact user information needs as user stories you are
not limiting the solution to "documenting." The information need may be
solved by embedding the required information in the GUI, or by redesigning
the feature, or by some other means.

"As an employee I need to know how to submit a timesheet." What's the best
solution? A "document"? A "manual"? Or something smarter, like an
automated e-mail notification with a hyperlink to a timesheet submission
interface that is completely intuitive and self-explanatory?

Specifying the exact information need as a user story induces the whole
development team to think creatively about how the information need can
best be addressed. A "manual" or help topic might be needed, but it might
not be needed if a better solution can be found.

The point is that the USERS specify what their information needs are, and
the whole development team (of which the tech writer or trainer or user
assistance specialist is a member) designs the best solution within the
relevant constraints. Users may decide they don't NEED, and won't pay for,
"documentation" of every feature. If they don't require it, you don't do
it. That's Agile.

Having the users define the exact requirements (and the words "a manual"
does not suffice as a requirement because at least half the "manuals" in
the world are worse than useless) is Agile. "Documenting" (whatever that
means) ain't. It isn't "a manual" they need. What they need most often is
the ability to perform a task, or the ability to understand what they are
looking at.

Mike West

A person using drawings, information and other data in or attached to this
email accepts the risk of:
* Using the drawings, information and other data in electronic form
without requesting and checking them for accuracy against the original
hard copy version
* Using the drawings, information or other data for any purpose not agreed
to in writing by the supplier

This email message and any attached files may hold confidential
information. If you are not the intended recipient any use, disclosure or
copying of this email is unauthorised. If you have received this email in
error please notify the sender immediately by reply email.


ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals.

Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control!

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Please move off-topic discussions to the Chat list, at:

Previous by Author: Re: I had to say it because I was afraid no one else would
Next by Author: Re: Should software documenters learn to read code?
Previous by Thread: RE: The Agile / Xtreme TW
Next by Thread: Storyboarding for an Established Application

What this post helpful? Share it with friends and colleagues:

Sponsored Ads