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: User Documentation in Agile Development Teams From:Julie Stickler <jstickler -at- gmail -dot- com> To:Technical Writing <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Fri, 24 Mar 2017 11:05:44 -0400
One of the tenets of Agile is "less documentation." But that means less
PROJECT documentation, not less USER documentation. Your users still need
to know how to use what you're producing and selling to them.
If you haven't met your support team yet, time to start building an
alliance. I always quip that my job as a Technical Writer is to reduce
support costs. And saying "It's intuitive" isn't really a valid excuse,
because of course it's intuitive to the people who designed it. They're
programmers! I've had many friends complaining on social media about the
fact that their new "intuitive" iProduct didn't come with a user manual and
they've had to figure out the features by playing around with it and
sometimes they still don' t know how to use the thing, even though they've
owned it for months or years.
You didn't say what your market is, but even when you're building products
for developers, they're still new to your technology and need documentation
to learn how to use it. (My last two companies have created products
mostly for developers, and trust me, they want docs!) End users who are
not in the technology business require even more documentation to help them
use products. Especially if there is some sort of recommended workflow,
or if their business processes need to be adapted to use the new product.
The definition of "Done" for each sprint needs to include code that is
tested AND documented. And unfortunately. many brand new agile teams learn
that the hard way. Agile came out of consulting, as a way to make
developers lives easier. But developers aren't the only stakeholders on
projects, and sometimes they need to be reminded that products are more
than just completed code. They're also tested and documented, and
customers expect that. QA, documentation, training, and localization may
also need to be included as stakeholders, and all of those groups need at
least some documentation to do their jobs for your customers.
On Fri, Mar 24, 2017 at 10:40 AM, Sue McKinney <smckinn2001 -at- gmail -dot- com>
wrote:
> Hello!
>
> I am a long-time tech writer very familiar with Waterfall development and
> am now getting familiar with Agile. I understand the idea behind lean
> documentation for what I call "back-end" documentation (e.g., requirements,
> user stories, design) but am trying to learn more about getting end user
> documentation into the development cycle. It's tough, given the frequent
> releases, and I now am faced with push-back from managers and developers
> claiming that documentation is way less important in Agile. In fact, it's
> just as important! Even though the software is supposed to "intuitive,"
> we're finding out that users want assistance; we're in the middle of
> creating online help for a second release of something that was deemed
> intuitive enough to not require online help for the first release. And
> then, of course, users complained about not know how to get their work
> done. I'm looking for ways to identify best practices for user
> documentation (online help, user guides) to present to management so that
> the new writer alone on a project has more credibility when he or she
> argues in favor of, say, online help.
>
> Any thoughts?
>
> Thanks!
> Sue McKinney
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Visit TechWhirl for the latest on content technology, content strategy and
> content development | http://techwhirl.com
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as jstickler -at- gmail -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and
> info.
>
> Looking for articles on Technical Communications? Head over to our online
> magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? Search our public
> email archives @ http://techwr-l.com/archives
>
--
Julie Stickler
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com