Re: Agile, Jira tickets, and document planning

[John G <john -at- garisons -dot- com>]

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>
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 -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
>
-- 
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

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -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