TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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. http://www.doctohelp.com
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! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
