Ewa Methodologies such as agile and scrum have almost completely replaced the waterfall model in the world of IT. At first, you would think that it’s best for a tech writer to write documentation in the waterfall model. It makes sense: the application is ready, so it’s time to prepare the user manual. However, tech writing in agile or scrum environment can also work perfectly, though it might be a bit more tricky at first.
Basically, you should adjust your tech writing strategy to your company, product, and your team(s). However, there are some universal strategies and tricks you can apply when writing early in the development process.
Task description and/or product notes
Task description in your project tool (e.g. Jira) or product notes should already tell you a lot about what needs to be documented. First of all, from a task description, you find out whether it requires documentation. Secondly, if there is a term, tool name, technology that you’re not familiar with, you can spend some time on Google search and additional reading.
If you feel like the task description is incomplete or doesn’t tell you much, reach out to the person who created it. It will help not only in your work, but the whole team will be grateful.
UX mockups
If some UX materials, such as mockups, are attached to the task, study them carefully. They should tell you a lot about the functionality. You can even start describing the procedure on the basis of mockups only. I sometimes go even a step further: I include the screenshots based on mockups so that I can see a new chapter as a whole. Then, after the new functionality is in the code, I exchange the screenshot, play around with the new functionality, and adjust my documentation. It’s surprising how much can be done even before the code is in the product. Of course, be careful: remember to check everything once the development is done.
Meetings
I would say that this strategy is the most difficult one because many meetings are very technical and it’s easy to lose focus. After working for some time as a tech writer, you’ll have a special filter in your head that will help you to get the most out of all technical meetings. At first, however, when you try to get to know the product and your team, it’s best to pay attention to everything. In order to survive the meetings, you can apply the following techniques:
- Make notes – the best way would be to do it in the form of mind maps. Note down things even if you don’t understand them at first – you can check everything after the meeting and verify if a given piece of information will help you with documenting.
- Ask questions – of course, be reasonable with that, but it’s always best to ask for clarification if your suspect that something might be related or have influence on documentation.
- When working remotely, you can ask your team if you can record a meeting. I sometimes do it when I know that the functionality I need to document is very complicated. Thanks to that, I won’t bother my team with too many questions later on – I’ll just watch the recording and analyze it carefully, pausing whenever I need. This strategy is also good when you feel a bit under the weather – I sometimes have days when I feel like I’m unable to understand anything. I think that’s all right as long as I can take some countermeasures and this state doesn’t influence my tasks.
If you suspect there will be nothing related to documentation during a meeting or it will be highly technical, clarify with your team if you are really needed. You can also ask them to let you know if anything related to documentation pops up and then you’ll join. Participating in a long meeting when you don’t understand a single thing can be really destructive for your work morale and if you do that frequently, it can even lead to professional burnout. That’s why it’s good to have that worked out with your team.
