How to Write Technical Documents in an Agile Software Development Project

How do you document a ‘moving’ feature in Agile? Today it’s blue, tomorrow green. One of the dilemmas for technical writers is trying to document new features between sprints.

The upside of Agile is that you get to see something, even a prototype, and can start documenting it in tandem with the sprints. That’s the theory.

The downside of Agile is that prototypes change.

So, what do you do?

• Wait until the prototype is completely finished, then document it?
• Document it from sprint to sprint to sprint?
• A bit of both?

Here are some thoughts on how to document new technical feature if you’re using Agile for development.

First, why is it difficult to document new features?

• The functional specification is vague, poorly written, or also a ‘living’ document. In other words, it changes too.
• The feature is changed with each iteration. Some things are minor IU tweaks, others are major overhauls.
• Documentation is supposed to be updated with each iteration.
• Finding change requests and changes is difficult if they are not tracked.

How to work around this?

• Review the requirements or functional specification (if they exist).
• Attend workshops, if possible. Ask questions about everything. Workshops are to learn.
• Discuss with business analyst how it’s supposed to work. Don’t assume anything.
• Discuss with developer how they intend to develop it, which could be different than what the BAs want.
• Discuss with QA how it’s being implemented, which again could be different that the original specs.

See if as a ‘fact-finding’ missing. Soak up as much information as possible. This is not the time to be shy.

Talk, ask, probe.

Then

• Document the new features in the first iteration
• Monitor the sprint backlog
• Review new tasks related to the feature

Things to avoid:

• Don’t take screenshots. Expect the UI to change.
• Confirm your understanding. Is this how it’s supposed to work?

My approach is as follows:

1. First, learn as much as possible.
2. Document the technical architectural. This helps you understand how it all ties together.
3. Document the conceptual materials.
4. Document reference material as it comes available, for example, API and other parameters.
5. Leave the procedures to the end. Changes to the UI may affect how the procedures work. Take screenshots near the end as these may change right up to the last minute.

What about you?

Download Technical Writing Templates

This Technical Writing template pack includes the following documents.

1. Audience Analysis – 30 pages
2. Data Sheet – 2 pages
3. Documentation Plan – 7 pages
4. Error Message Guide – 14 pages
5. Fact Sheet – 2 pages
6. FAQ Template – 17 pages
7. Installation Plan – 22 pages
8. Product Document Plan – 14 pages
9. Quick Start Guide – 14 pages
10. ReadMe Template – 2 pages
11. Release Notes – 17 pages
12. Setup Guide – 29 pages
13. System Admin Guide – 35 pages
14. Troubleshooting Guide – 12 pages
15. User Guides – 5 x 16 pages

Image may be NSFW.
Clik here to view.

Download 15 Technical Writing templates to write technical documents faster