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.
I agree with Johnâs comments and questions. I work as a tech writer embedded on a scrum team. My companyâs been working in Agile-Scrum since around 2013, and weâve included tech writers in teams the entire time.
For our process, our docs tasks are part of the main development stories in JIRA. Part of each team's definition of done is having documentation thatâs ready to publish. In my team, I work closely with the developers and with QA to make sure that our docs are comprehensive, accurate, and are appropriate for the audience (our users). Because docs is part of the definition of done, our developers factor reviews into the overall workload and story estimates (and if they donât, we kindly remind them). To us, docs don't âhold upâ development because the documentation is a part of it.
My coworker Sarah Kiniry and I (sheâs also in TechWhirl) have an STC Webinar, coming up on April 11, where we explain how our docs process works with Agile. You will find more information on that here: https://www.stc.org/event/nine-writers-nine-agile-teams-one-voice/ <https://www.stc.org/event/nine-writers-nine-agile-teams-one-voice/>. We currently have 10 writers working on 10 teams (we hired another writer between the time we started our webinar proposal and today). If you are curious to see our process, I would highly recommend attending.
Best,
Rosie
Rosie Arcelay
Technical Writer II
cPanel, Inc.
rosie -at- cpanel -dot- net
> On Apr 3, 2018, at 6:28 PM, John G <john -at- garisons -dot- com> wrote:
>
> Iâm gonna ask some questions before I can provide any suggestions. Little
> background: I have worked in Agile and agile-ish environments for over 8
> years supporting multiple teams and concurrent projects.
>
> 1. How much info is in Jira - for the epics as well as the stories? The
> more background information, the better - both for you and well as anyone
> else in a support or ancillary role.
>
> 2. How are the SQA folks going to test this? I have found that QA is a
> natural ally - they can demo stuff for you and you can grab screen shots
> when they do, and you can use their test plans to figure out what is
> supposed to happen.
>
> 3. What do you have to deliver as documentation? Is this end-user
> documentation, or internal how-the-code-actually-works documentation? How
> much overhead do you have to deal with?
>
> 4. When does the documentation have to be delivered, and what does their
> SDLC have to say about code freeze and testing time, and what kind of
> buffer does that provide for you?
>
> 5. How disciplined is the development team? If you assign tasks to
> developers, testers, product owners, how responsive are they likely to be?
> Will they recognize you saying âIâm blockedâ as a real problem, or will
> they sweep it under the rug?
>
> 6. Does the dev team have revels for every sprint? If so, make sure you
> attend and fill the role of the userâs advocate. If there are things they
> can do to make the userâs job easier - reduce the number of hoops that must
> be jumped through - provide that input.
>
> All that said - focus on what you have to deliver and prioritize the
> content that will be most useful to the primary audience and do that first
> and best. If the environment allows, do an adequate job on everything, and
> the best job on the most important stuff. Recognize that there is likely
> time to improve things once the initial release has been made.
>
> In my experience, it is not generally required to deliver complete
> documentation at the end of every sprint. In almost every instance I have
> experienced a release includes one or more epics, and each epic includes
> multiple stories. Depending on the size and complexity, initial sprints
> often focus on internal structure, and only the latest sprints determine
> the details.
>
> My 2Â,
>
> JG
>
> On Tue, Apr 3, 2018 at 3:54 PM Stuart Conner <stuart2 -at- stuartconner -dot- me -dot- uk <mailto:stuart2 -at- stuartconner -dot- me -dot- uk>>
> wrote:
>
>> I'm in a new job where I need to plan and produce some documentation in an
>> Agile environment.
>>
>>
>>
>> I have a known number of documents to produce within the next 3 months,
>> with
>> each sprint being 2 weeks long. The order in which the documents are
>> produced is not critical.
>>
>>
>>
>> Each document will require the following sequence of activities: (1) A
>> developer SME either writes an initial draft of the document or conveys
>> that
>> information to me verbally, (2) I produce a good draft of the document,
>> gathering further information from the SME as needed, (3) review, further
>> rework and eventually sign-off. All the usual stuff.
>>
>>
>>
>> The main pain-point is going to be getting developer time to work on the
>> documentation, as they have code to develop as well. We'll raise a Jira
>> ticket for each document so the necessary time can be planned into each
>> sprint.
>>
>>
>>
>> My question relates to the best way to track things in Jira:
>>
>>
>>
>> (1) We could say that for each sprint, the developer and I will work on
>> documents A, B and C, and we raise Jira tickets for these. But doing this,
>> developer time will be needed early in the sprint if he/she is to do their
>> part leaving enough time for me to rework and finish the draft before the
>> end of the sprint. If the developer gets tied up with other stuff during
>> the
>> first week of the sprint and can't look at the documentation until the
>> second week, then I won't have time to complete the documents before the
>> end
>> of the sprint.
>>
>>
>>
>> (2) We could separate the developer's time on the documents from my time.
>> So
>> for each sprint, the developer will work on initial drafts for documents A,
>> B and C, and I work on the drafts the developer produced in the last
>> sprint.
>> More flexible, more likely to finish the work scheduled for each sprint,
>> but
>> double the number of Jira tickets to be tracked.
>>
>>
>>
>> (3) We could say that for each sprint, the developer will work on documents
>> A, B and C, but I will work 'outside' the sprints, being flexible on how I
>> work on the drafts produced by the developer. I track my progress on the
>> documents separately. We don't drown in Jira tickets. But to some extent
>> I'm
>> working outside the Agile team.
>>
>>
>>
>> Anyone been in a similar situation and have any advice on what worked for
>> them?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Stuart.
>>
>>
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Visit TechWhirl for the latest on content technology, content strategy and
>> content development | http://techwhirl.com
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> You are currently subscribed to TECHWR-L as vwritert -at- gmail -dot- com <mailto:vwritert -at- gmail -dot- com>.
>>
>> To unsubscribe send a blank email to
>> techwr-l-leave -at- lists -dot- techwr-l -dot- com <mailto:techwr-l-leave -at- lists -dot- techwr-l -dot- com>
>>
>>
>> Send administrative questions to admin -at- techwr-l -dot- com <mailto:admin -at- techwr-l -dot- com>. Visit
>> http://www.techwhirl.com/email-discussion-groups/ <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 <http://techwhirl.com/>
>>
>> Looking for the archived Techwr-l email discussions? Search our public
>> email archives @ http://techwr-l.com/archives <http://techwr-l.com/archives>
>>
> --
> Sent from my iPad, please excuse any automatically created mis-corrections
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com <http://techwhirl.com/>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as rosie -at- cpanel -dot- net -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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com