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.
>Hi, guys...one of the products for which I'm handling the
>documentation is attempting the use of the Scrum development process
>for this release. What tips and techniques you can pass along that will
make my
>participation more productive.
We've been following scrum methodology for some time now. While it works
well, it does take some getting used to, particularly from a
documentation perspective. Are you joining an existing team that has
been working with scrum for a while, or are you all new to the process?
If the former is true, the team may already have worked out a way to
incorporate documentation. In that case, your scrum master or product
owner would be your best resources.
Some things to keep in mind:
Scrum is in many ways a numbers game. Some things you'll need to
estimate and track are:
- The percentage of your work time spent on the team's stories.
- The number of hours you think you'll need to complete each task. In
scrum, this is public knowledge, discussed daily.
- The number of scrum iterations (counted in weeks or months) that will
make up the release cycle.
Scrum can sometimes mean you get fewer traditional artifacts like specs
and design docs. If this is the case on your team, make doubly sure
sufficient time is scheduled for technical interviews, demos, hacking,
and so on. Likewise, in scrum, informal communication can sometimes
trump formal meetings, particularly in setting where all team members
sit in close proximity. Make sure you hear about and attend relevant
discussions.
If you are not the sole writer on the scrum team, you and your doc
colleague(s) should come to some consensus on estimates. For example,
say a more junior colleague was working with you on your team. A task
that might take you a day and a half could take her closer to a week.
The team as a whole needs visibility into this discrepancy while you are
scheduling the work for the iteration.
As much as possible manipulate the flow of work so that it arrives
smoothly throughout the iteration and not all at once in the final week.
For example, if a developer can choose between Task A, which will result
in work you can take on early in the iteration, and Task B, which won't
be ready for you until the end of the iteration, don't be afraid to
advocate for her to take on Task A first. After all, it's in the whole
team's interest that you meet your commitments for the iteration.
Finally, make sure you and all the team are clear about the criteria for
completion of your documentation tasks.
Good luck with your project. I think you'll find scrum a good way to
work.
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
