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.
We have a Definition of Done which includes doc, but until we have more writers I am in favor of having it removed because it is becoming too hard to keep up. Quality is slipping. I am less visible so teams aren't even adding doc tasks like they used to, and when the stories are almost done they are like, oh yeah, that needs documented!
I don't have a real SM, nor a PO. It has gotten, as we said in the old days, "all jacked up." Other teams do of course.
First, if you are blocked on a feature topic, or you have more to do than you can handle in one sprint, the Scrum Master should cut back on the development in the sprint, or should hire another writer.
Second, you probably had too many developers to keep track of to start with, and the number you've got now is way too many. In Scrum, they say "if the doc isn't done, the sprint isn't done either" and the writer-to-developer ratio is a big factor in the doc not being done.
If you don't have the support of the Scrum Master to either get you some help or limit the number of features in the sprint and/or release, then you should cut back on how much you provide in the documentation, at least in that release. Can you provide procedure steps and forget about conceptual material for now? That's one way to handle aggresive deadlines without regard for how much work the documentation is. Another strategy: QA's test cases can become procedure steps. Get them to help you with the steps and procedures framework and you can format it for the documentation.
I have worked on five agile projects now, and in self defense, I read everything I could get my hands on about Scrum. That's why I know that "if the doc isn't done, the sprint isn't done either." Read it and quote it. If they are trying to follow Agile Scrum, they have to agree with you!
On Tue, Sep 14, 2010 at 1:11 PM, Kat Kuvinka <katkuvinka -at- hotmail -dot- com> wrote:
I really like it at first! There was one me, one tester, three teams, and about a dozen developers. Docs were part of the DoD and I thought it was a great way to be on top of every new or changed feature.
Now there are 7 teams, about 30 developers, 6 testers, and still one me. OK, I exaggerate, we have a contract writer, but she is dedicated to one team, and I still have to support that team. And she is leaving soon.
I am going to campaign for more writers, but in the meantime, any suggestions?
Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days. http://www.doctohelp.com
LavaCon 2010 in San Diego Sept 29 - Oct 2 is now open for registration.
Use referral code TECHWR-L for $50 off conference tuition!
See program at: http://lavacon.org/
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-