This topic addresses this question:
Now we are using Agile and hardly create BRD\FRD, we create user stories, and all this is good for everyone working in the same department. Including the stakeholders. However, if I would like to share the requirements with a person in any other department, who has not heard of Agile. How can convey what the product will do? I can give a demo and I can tell the rules, but they might not remember all, and won’t be able to refer to something substantial. I can write a document and read it to them with details, but I don’t like the idea of reading from a document… Also, I could add pictures to it and make it little interesting. However, for this I will need to go through user stories and create a document and I don’t think is the best way. So, please guide me how can I solve the problem of sharing the details of a project (requirements, limitations, etc) to a non-technical person. Thanks!
It is useful here to remember the role of a business analyst. One of the more important things that a BA must do is communicate clearly and meaningfully so that they deliver real results for their organisation.
So in saying this we must do what it is required to get the information across to the stakeholders.
The key is in understanding your audience and ensuring that you have adapted the delivery of your work so that the requirements are communicated according to their needs. People have different learning styles. A document full of user stories may be tedious and difficult to absorb for one person, but for another person, the only way they want to take in the information.
Me personally, I am a visual learner, but there are those who learn best by reading, and those that learn through listening. So, try to adapt to all learning styles. Unfortunately, we have to overcome our lack of preference for reading to be effective in our role. It is simply something we cannot avoid.
For my stakeholders, I generally deliver the information through a combination of presentations and documentation containing diagrams and written content. Again, knowing your audience helps. A senior manager wants the business relevant overview, whereas the technical people want to see details.
Disregarding methodology, I almost always write user stories and scenarios for the acceptance criteria. This is because I have found this was the best way to communicate to the business stakeholders in business natural language, but also so technical audiences can translate requirements into an implementable system.
I include a high level conceptualisation of the proposed solution in diagrammatic and written form, so that the audience can visualise the solution without dictating technical details. This also consolidates my understanding of the requirements and tests for gaps.
I also group user stories by process or I group them by organisational capabilities and the functions of the capabilities respectively. I will create a high-level overview diagram showing the process or capability map, and the document subheadings come from the process overview/capability map which contains the relevant user stories.
It all really depends what communicates best and there will be other ways of slicing and dicing user stories, but these two examples have worked for me. The key to it is that you are linking the user stories to a higher level conceptualisation of how the audience relates to their business. This gives the stories meaning.
There is no magic bullet for transferring vital information into stakeholders’ heads. This is the job of the business analyst. If you can do this well, through verbal and written forms, then your value as a BA will exceed.