Re: How Do You Decide How Long Things Will Take (in a SCRUM Shop)?

[Pro TechWriter <pro -dot- techwriter -at- gmail -dot- com>]

Others have made some great points. Now, I'll add my experience to the mix
:-)
This is my third agile team, and so far it is the best I've been on. The
problem with estimating documentation in an agile shop is always an
interesting one to solve.

In the first place, I do not provide a "time estimate" for documentation. I
provide "story points" that indicated the *degree of difficulty*, not how
long it takes. This may or may not correspond directly to days during the
sprint. It is likely that you will need to trail behind the developers in
sprints. The developers create user stories in the application we use to
track such things, and I place a DOC: task against each story with a quick
description of what needs to be done, and an estimate, which I
sometimes characterize as a "wild guess."  (Also note that the definition of
"estimate" might need to be explained to your boss.)

We start our sprints on Wednesday and end them three weeks later on Tuesday.
(Note that your 7-10 day sprints are extremely short in my experience.) So,
Wednesday through Friday of the following sprint are the days that I put the
finishing touches from the previous sprint and post the Help to the server.
I also catch up with the topics that were checked in ("thrown over the
wall") on the last day of the sprint if I can. Those, of course, can't be
documented if I cannot see the feature until sprint review! QA also is a
half- to a whole sprint behind as well.

Agile by its very nature is good for quick turnaround and matching small
chunks of documentation to features. To begin doing that, you have to be
ready to keep revising the structure, and be very flexible with what you
create. Start with general topics and drill into specifics afterward. Write
concept topics for half-finished features, and do the tasks later when the
feature is complete.  And reuse everything you can as far as text and topics
go. As a writer on an agile team, I have had to let it be known that I have
to be in the loop 100% of the time, or I can't do my job. We have a saying
here: If the doc isn't done, the story is not finished. The documentation
has to be on equal footing for importance or it is very hard to be
successful.

One other idea that goes with agile is "Make it good enough; not perfect."
That means that there may be bugs in the software, and there may be errors
in the documentation, but we will make it better next time."

I know agile is a shock after working other ways, and documentation and
writers often do not get the respect and assistance that they need to be
successful in that environment. Take the other's suggestions and start
reading up on agile as a methodology. Ask for mini-specs and access to your
own build of the software. Do you all do sprint planning together? Pay
attention to what the developers have scheduled, and when you are at
capacity, raise your hand and say, that's all I can do this sprint. If you
have access to QA, work with them, because they are in the same boat you
are.

Hopefully some of this advice will help you. It's a great start for my blog
article about agile tech writing :-) So thanks for that!

Feel free to email me off list if you want more specific suggestions!

PT

On Wed, Jun 17, 2009 at 1:42 PM, Guy McDonald <GMcDonald -at- lgc -dot- com> wrote:

> Hi Yannia -
>
> Our shop is 100% AGILE, and I am a CSM (Certified ScrumMaster).
>
> After reading your mail, it is clear to me the problem lies with your
> implementation of the methodology. The biggest issue I see is the focus on
> being spot-on with the story size & time estimate for each task.
>
> One of the strengths of Agile is the flexibility it affords each team,
> especially as it pertains to scheduling. I would suggest you read some of
> the articles at http://scrumalliance.org and share them with your team.
>
> It is sometimes very difficult to get out of the waterfall mindset. Some
> people can cling to a rigid method and have trouble adjusting to using
> Agile. Adjusting estimates is a common occurrence with any healthy Agile
> team. Over time, you get better with your estimation. The sizing of stories
> helps your product manager plan when to schedule the development of
> features. However, the actual time estimation is not a hard number. You may
> get into a task and discover it will only take you half the time you
> originally thought. Likewise, it may take longer. The important thing is
> that you COMMUNICATE with your team on a daily basis (sometimes hourly) of
> any difficulties you may have. If you finish your iteration early, help
> another team member out. Who knows, you may enjoy a little testing  ;-)
>
> Take care and please do not let the growing pains you folks are
> experiencing with Agile to influence your attitude about the method. I
> suggest after you read a few articles from the web site I mentioned, that
> you meet with your Scrum leader and have a positive discussion. If that
> doesn't get through, then run the flagpole up to higher authority.
>
>
> Guy
>
>
> -----Original Message-----
> From: techwr-l-bounces+gmcdonald=lgc -dot- com -at- lists -dot- techwr-l -dot- com [mailto:
> techwr-l-bounces+gmcdonald <techwr-l-bounces%2Bgmcdonald>=lgc.com@
> lists.techwr-l.com] On Behalf Of Yannia Vodrovich
> Sent: Wednesday, June 17, 2009 1:08 PM
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: How Do You Decide How Long Things Will Take (in a SCRUM Shop)?
>
> Hi all
>
> I am a captive TW at a small software co now. I am having a devil of a time
> at an agile scrum shop . I am new and am charged with giving estimates to
> the microsecond to a micromanager of how long things will take to put on the
> Product Backlog (list of how long things will take and then check off as we
> go through the "Sprint' toward the release) , for software that I am
> (obviously) just learning, for documentation (totally online help format,
> using Help and Manual) that I also am just learning.
>
> The difficulties are obvious: I don't always know (1) how thorough the
> documentation is that is already there. Sometimes I can go look and figure
> it out, sometimes I can't as there is not enough time to dig or it is not
> obvious as there is topic overlap; (2) I am just learning the software which
> is moderately complex to complex; and (3) there are intervening things that
> come up, as do things at any job, and being new (2.5 months) I don't totally
> have a feel for that either.
>
> My first estimates that I gave, I gave myself a lot of wiggle room but the
> micromanager seemed bewildered and said they seemed high and was worried
> because I also have another hat to wear, working for the Training
> Department. So I adjusted them down a bit, with hesitation, and the
> micromanager is upset because I am running out of time. :-) This guy is
> really driving me nuts.
>
> I need to give him specific time estimates, to make him happy,  for each
> little piece of coding that the developers do, ahead of time (if you have
> ever worked with a scrum agile shop) which - the jury is in, I am finding
> that I dislike very much. Somehow I have to predict the time, but I can't
> give too much time but can't run out of time either, and I have to do this
> as a totally new employee.
>
> I have gotten together with the QA person and two developers before each of
> the last two "Sprints" to ask what the hard easy and medium sections of the
> software are, and I have looked at the documentation and categorized it by
> "Sparse, medium , and Well-Documented' to aid in my estimates. Beyond that,
> I talk to everyone I can, but somehow my estimates are just not working.
> They are leaving me like running over by 2 days that makes him upset. And
> working overtime gets old quick at this stage of my life. Short of polishing
> up my Crystal Ball, I don't know what to do. His phone calls are getting old
> (he is in another office). he says it nicely but he annoys me. Micromanaging
> really gets under my skin.
>
> Actually he is not my true boss. My true boss is the Training guy. they did
> that to write my salary off to a client since training is client-based. so
> that is good. But he is like a dotted line relationship - and till the
> training stuff kicskup I have to deal with him A LOT . Lucky me! The
> Training mgr says everyone in Training hates him and is afraid of him - and
> that even he 9the Training mgr0 has problems with this guy because of his
> condescending attitude and strong personality etc.
>
> Anyway, I have been a TW for a long time but nowhere I have ever worked
> have I been expected to hit the mark to the nanosecond and not be too high
> or too low and get hanged either way.
>
> I just don't know what to do.
>
> At any rate, I need help - how do you guys, esp. those in a SCRUM shop deal
> with this? Has anyone been through this? I am going nuts. How do you figure
> in the "unknown' wiggle room? And once you do how do you defend it on a
> Product Backlog? What do you call it and sound respectable to a
> micromanager? What name does it get on the Excel sheet?
>
> Thanks
>
> Y
>
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Free Software Documentation Project Web Cast: Covers developing Table of
> Contents, Context IDs, and Index, as well as Doc-To-Help
> 2009 tips, tricks, and best practices.
> http://www.doctohelp.com/SuperPages/Webcasts/
>
> Help & Manual 5: The complete help authoring tool for individual
> authors and teams. Professional power, intuitive interface. Write
> once, publish to 8 formats. Multi-user authoring and version control!
> http://www.helpandmanual.com/
>
> ---
> You are currently subscribed to TECHWR-L as GMcDonald -at- lgc -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/gmcdonald%40lgc.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
>
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient.  Any
> review, use, distribution, or disclosure by others is strictly prohibited.
>  If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Free Software Documentation Project Web Cast: Covers developing Table of
> Contents, Context IDs, and Index, as well as Doc-To-Help
> 2009 tips, tricks, and best practices.
> http://www.doctohelp.com/SuperPages/Webcasts/
>
> Help & Manual 5: The complete help authoring tool for individual
> authors and teams. Professional power, intuitive interface. Write
> once, publish to 8 formats. Multi-user authoring and version control!
> http://www.helpandmanual.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
>
>


-- 
“You can only become truly accomplished at something you love....Pursue the
things you love doing, and then do them so well that people can't take their
eyes off you.”

- Dr. Maya Angelou
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help  
2009 tips, tricks, and best practices.
http://www.doctohelp.com/SuperPages/Webcasts/

Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.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-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.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