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.
It is not a best practice to lag behind a sprint because that goes against
the spirit of Agile, especially if you are using SCRUM. The documentation is
just as important a component for the sprint as the code or QA tests, and,
as our SCRUM expert used to say, "If the documentation is not done, the
sprint isn't complete either."
There is a compromise, though, that I used. Our team had three week sprints
that started on Wednesday and ended on a Tuesday. We did our sprint
retrospective on Tuesday, and started the next sprint on Wednesday. Since
that starting Wednesday and Thursday were usually background tasks (coding),
there was not as much for me to do right at that moment.
So Wednesday through Friday were my "finish up" days if I had anything left
over from the sprint. I also used that "slack time" for features that just
appeared during the sprint retrospective with a brand-new feature that no
one had seen or created a user story for. That happened when the product
manager and one particular developer got together and cooked up features
without telling anyone until they were done. That also goes against the
spirit of Agile, but it does happen.)
Agile documentation is now my favorite way to work. Communication is key,
and you may have to really speak up when you have enough work during sprint
planning, determined by your estimate of what it takes to document a certain
story or stories. *Your* estimate, NOT their estimate. Everyone on an Agile
team makes their own estimate about how long their work with take them to
do.
Book your documentation tasks against the user story that the devs are
coding. That way, when they are late with code or don't finish something,
you can show that you are blocked on a task, and go on to the next one. It's
the ultimate in accountability, and that's a good thing. The whole team can
see right away how their actions affect the documentation being on time as
scheduled.
I could tell you "it's going to be fine" but you will have to experience
that for yourself, I suspect. Do some reading about the Agile SCRUM process
so you know what is supposed to be happening, as opposed to what others are
telling you. And speak up! Everyone's input on an Agile team is critical.
They need your viewpoint too, and you might find that you really start to
like that.
Best,
PT
On Fri, Apr 9, 2010 at 8:11 AM, Blount, Patricia A
<Patricia -dot- Blount -at- ca -dot- com>wrote:
> Good morning, all,
>
> I learned last week in strategy conference that my company plans to
> adopt an agile development process. For us, that means switching from an
> annual software release cycle to a monthly one. I've devoted a good deal
> of time since then to researching agile methods, trying to learn how
> tech writing fits into such a process. (Tom Johnson, Sarah Maddox and
> Anne Gentle all have incredibly detailed blog entries on this topic. I
> began my research there.)
>
> So far, I know we'll be focusing on just a few tasks per sprint. So it's
> probably less writing than we're used to. But it has to fit into a much
> smaller schedule, so I'm sure there's still a mad scramble to get it all
> done.
>
> I've got a few concerns... chief among them: Does tech writing fall off
> the radar in such environments? Rumor hear has it that tech writing will
> lag a sprint behind development. I think that's a bad idea because we
> typically do more than 'write'. We review GUI screens for grammar and
> sense, we suggest design improvements when instructions feel clunky, we
> can test as we write, so if we lag a sprint behind, those problems won't
> be fixed immediately (and isn't that the goal of agile?)
>
> Does anybody have agile tech writing experience? Could you share a
> little of what the typical sprint feels like?
>
> Thanks,
> Patty B.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
> produce desktop, Web, or print deliverables. Just write (or import)
> and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
>
> Explore CAREER options and paths related to Technical Writing,
> learn to create SOFTWARE REQUIREMENTS documents, and
> get tips on FUNCTIONAL SPECIFICATION best practices. Free at:
>http://www.ModernAnalyst.com
>
> ---
> You are currently subscribed to TECHWR-L as pro -dot- techwriter -at- gmail -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit
>http://lists.techwr-l.com/mailman/options/techwr-l/pro.techwriter%40gmail.com
>
>
> 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
>http://www.techwr-l.com/ for more resources and info.
>
> Please move off-topic discussions to the Chat list, at:
>http://lists.techwr-l.com/mailman/listinfo/techwr-l-chat
>
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
Explore CAREER options and paths related to Technical Writing,
learn to create SOFTWARE REQUIREMENTS documents, and
get tips on FUNCTIONAL SPECIFICATION best practices. Free at: http://www.ModernAnalyst.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
