As a business analyst you will have to write documentation and you have to be able to do that very well. Whether you are working in agile or you are working in waterfall, you will need good documentation. Having good documentation skills is important to grow your business analyst career.
Documentation in an Agile Environment
The agile manifesto says “working software over documentation” that does not mean that you don’t have documentation in agile. Business analyst documentation skills is still needed in agile. Many people who are working in very agile shops use their user stories as their main documentation, however, this may not be enough. If you have to share information with other team members, clients, vendors or partners, you will need to write additional documentation that is tailored for these audiences.
Documentation in Waterfall Environment
On the waterfall side you’re already in heavy documentation and you are creating the business requirements document (BRD) that lists out everything that you’re going to build. The BRD is great for both the technical team and us business analysts, but sometimes it’s too much for your technical writers, for your customer service people, for your support people etc… Therefore you will also need to create supplemental documents that serve your other audiences also when working in waterfall.
If you need a template to get you started on writing your BRD, you can download my BRD template here
Documentation Skills to Note
You can document in any tool but off course Microsoft tools are the most common, namely Microsoft Word. Typically you will create your document with the relevant based on your audience and the intent of the document.
Of course you will include in your table of contents and table of figures as well. Its great if you can use appropriate line spacing to make sure the text is easy to read. 1.5 is usually enough.
You should also be sure to number your requirements or your acceptance criteria and not bullet them. This is because it is easier to refer to a number than a bullet position.
Its also good practice to categorize your requirements, such as configuration requirements versus user requirements, versus system requirements etc… For acceptance criteria it is good to call out actions based on the use type such as admin versus end user.
Include pictures as much as possible, it really helps with sharing understanding when we show a picture rather than text.
Final Thoughts
Always do what works for your organization, do not feel the need to stick to what experts say or any books says. Do what works!
When you spend all this effort writing documents, you have to make sure the document is accessible. Make sure you save it somewhere everyone who should see it, can access it.
To find out more about the documents a Business Analyst produces, please check out this video where I walk you through the top deliverable expected of business analysts: BA deliverables video