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:"Annette Reilly" <annette -dot- reilly -at- computer -dot- org> To:"'Sue McKinney'" <smckinn2001 -at- gmail -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 30 Mar 2017 22:22:40 -0400
There is actually an international standard about this, ISO/IEC/IEEE 26515:2011, Systems and software engineering â Developing information for users in an agile environment. A new edition should be out next year, but the original has many useful practices and even some testimonials from people who have applied it.
-----Original Message-----
From: Sue McKinney [mailto:smckinn2001 -at- gmail -dot- com]
Sent: Friday, March 24, 2017 10:40 AM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: User Documentation in Agile Development Teams
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