*Due to web issues, we lost information on who authored this piece. If this is your work, please let us know and we will give you publishing credit.*
The main principle of agile development is that all members of a product team sit and work together, developing code, writing documentation, testing, and providing quality assurance. Technical writers benefit from this early involvement because documentation is considered part of the product, and documentation development time is factored into the product release.
Agile development increases the quality of deliverables and helps technical writers cope with change more efficiently. Often, development and documentation work on the same problems at the same time. When the whole team takes responsibility for quality, the quality of the product goes up.
Here are some of the basic terms used in agile teams:
- Iteration — A period of time during which software is programmed and at the end of which the quality assurance (QA) testers verify that the software is working as expected.
- Stand-up — A daily meeting in which the progress of the software development is communicated.
- Story — The business needs that define what the software will do for the user. Stories are usually sized so that a single iteration is enough time for development.
- Task — Defines all of the subtasks for a single story. For example, for the story “An administrator can add a new user,” one of the tasks might be “Connect the new component to an existing security component.”
- Backlog — A repository for stories that are targeted for release during an iteration.
As a technical writer, you will be most successful when you are dedicated to a single agile team, not a resource shared by several agile teams. This enables you to attend all meetings, where you can gather information and overcome roadblocks. You can also agree with the development team on how many iterations the end-user documentation can lag behind the completion of features.
The best agile teams understand the value of documentation and that an integral part of creating successful, working software is excellent documentation.
Have something to add? Please share it in the comments.