How Can We Help?

Technical Writing in an Agile environment

You are here:
< Back

It works best when the technical writer and development team negotiate a mutually acceptable working arrangement. One size does not fit all.

Here are some of the questions that should be approached:

  • Should documentation be managed as items in an engineering sprint?
  • Should the document reviews be assigned story points?
  • Do you still create a documentation plan at the project kick-off if you are following an agile scrum process?
  • How can you keep pace in documenting features during the sprint if the features don’t get finished until the end of the sprint?
  • How can you reduce the tedium of daily stand-ups when engineers seem to rattle on endlessly about coding issues?
  • How can you stay updated about JIRA items when engineers don’t take the time to articulate the issue but rather hastily add a quick title that only they and other engineers who are already familiar with the issue understand?
  • How can you persuade engineers to dedicate time for doc reviews if there are no points allocated for the work in the sprint?
  • Logging bugs changes the role tech writers play on teams. Should tech writers log bugs when they find them, or simply send emails to the QA engineers to log the bugs?
  • What processes should tech writers follow in order to publish rapidly during the two-week cycles, especially when tech writers have several projects at once, all of which have two-week release cadences?
  • How can technical writers be valuable participants in the agile process when they are part of 3+ different teams, each of which has its own daily standups, sprint planning, and retrospective meetings?
  • Agile teams often follow a “fail quickly” approach that leads to coding in a lot of different directions in order to find something that works in the market. How can you avoid massive revisions of your documentation with each major direction during this highly volatile period of coding?
  • Agile teams often want to minimize the amount of documentation in order to stay agile and flexible (the principle is “working software over comprehensive documentation”). How do technical writers negotiate the de-valuation of documentation on agile teams (even if the docs mostly refer to project documentation instead of user documentation)? How does minimalism factor into agile practices?
  • What time management techniques can you implement to be more efficient in order to meet the fast-paced demands of agile teams? What can you ignore or cut out of your day? Are all meetings necessary to attend in order to convey the importance of your role on the team?