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.
RE: How Do You Decide How Long Things Will Take (in a SCRUM Shop)?
Subject:RE: How Do You Decide How Long Things Will Take (in a SCRUM Shop)? From:Guy McDonald <GMcDonald -at- lgc -dot- com> To:"'Yannia Vodrovich'" <coralfire -at- rocketmail -dot- com>, "techwr-l -at- lists -dot- techwr-l -dot- com" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Wed, 17 Jun 2009 13:42:18 -0500
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=lgc -dot- com -at- lists -dot- techwr-l -dot- 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?
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-
----------------------------------------------------------------------
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 archive -at- web -dot- techwr-l -dot- com -dot-
