By Manjusha Nair

As technical writers, we rely heavily on design documents and prototypes to get an understanding of the product/software; the absence of this basic arsenal can stump the best of writers. But there are alternatives…

We discussed in the last article how agile does not follow any pre-determined process, and does not rely on documentation (internal specifications documents). For a technical writer coming from the traditional waterfall scenario, it is perceivably daunting to start work on such a project. Let’s look at the requirements gathering process that works best in an agile environment.

Getting started

A good starting point is the user story. Look at it to understand whatever you can of the size, nature, and complexity of the feature you are documenting. Once you’ve read the user story, you will undoubtedly have questions. This is a good sign – you must immediately start asking these questions. The sooner you get answers, the sooner you can start writing the draft.

The power of meetings

Kick the old waterfall habit of relying on the design documents and start relying on one-on-one interaction and impromptu meetings instead. Scrum team members usually sit close to each other, which is a blessing for the writer, who does not have to chase elusive SMEs over chat and email.

Don’t wait for developers to respond to your email requests. Just visit them in their cubicle, and have quick meetings to resolve doubts and get clarifications.

You will be meeting your scrum team everyday for the ‘daily stand up meeting’, which is is nothing but a status update meeting where each member of the team talks about what they did yesterday, what they are doing today and whether there’s anything blocking them. Articulate any problems you may have in the daily scrum meeting; make use of this meeting to bring up anything that you may need from any of the scrum members.

Agile works best if all members of the team are co-located and most organizations make an attempt to co-locate their agile team members. This is how everyone has access to their team almost constantly. This ensures that work carries on as per schedule and everyone is on the same page. That said, you may be working with a team member in another location (onsite/offshore). In such cases, fixing up a set time to interact and get clarifications would work best.

Keep records for tracking

Keep a document/notepad/spreadsheet in which you record everything. Because things are happening on the fly, it’s very difficult to keep track of everything if you just commit it to your memory.

Always send MOMs after meetings, even if it’s an impromptu one-on-one. This might take a few minutes of your time, but will keep everyone sane in the long run.

I use different colored cells in a spreadsheet to track the requirements. Sometimes developers are not sure of the feature and will ask for some time to figure it out and get back to you. Mark these things in your tracker and go through it before every stand up meeting, so you can bring up anything that’s blocking you.

Even though initially daunting, agile actually works well for a writer gathering requirements. Agile lets you form close networks with your team: be proactive, friendly, hold your own, and in the end this methodology will not fail you. Proximity to the SMEs and meeting them every day will perhaps work even better than the traditional waterfall projects ever did.

In the next article in the series, we will discuss developing documentation in the agile environment.

About the Author

Manjusha Nair is a content specialist working with Infosys, Bangalore. She is passionate about innovation and sharing knowledge. In her spare time, Manjusha likes to write poetry and fiction.