Need help- Documentation for non-technical people using Agile

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; however, I can tell the rules and however, they might not remember all, and won’t be able to refer to something substantial. If I write on a document and read it to them with details. Here, I don’t like the idea of reading from a document because it gets boring. 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, this 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!

Answer 1

TL;DR

There is no silver bullet. However, it is likely that your organization needs to adopt a more comprehensive set of agile tools and practices to reduce unnecessary or burdensome documentation.

Agile Practices Often Deliver Better Documentation

Your question is possibly too broad to answer, but I'm going to go out on a limb and guess that your organization has recently transitioned to "Agile" (whatever the organization thinks that means) without having actually adopted the complete framework, or without implementing common agile practices like Test-Driven Design (TDD) or Behavior-Driven Development (BDD). This is likely the source of your problem.

Agile frameworks value working products over extensive documentation. The Agile Manifesto says:

Working software over comprehensive documentation...[T]here is value in the items on the right, [but] we value the items on the left more.

This doesn't mean agile teams don't document anything. In fact, high-performing agile and DevOps teams often produce more useful documentation than they did before adopting agile practices. This is generally because:

1. "Living documentation," like well-commented and frequently refactored code, is often more accurate than dead-tree hieroglyphics from the misty dawn of time when the initial requirements were most likely generated.
2. When properly-written, TDD/BDD/ATDD tests read like natural-language documentation, and often incorporate terms and concepts from the the product's business domain and a user's point of view.
3. Continuous integration using good tests ensures that your documentation remains both current and accurate, which is something that most traditional projects fail miserably at.
4. End-user or system documentation (if and when actually needed) is often compiled programmatically from code comments, executable tests, API signatures, and so forth. Note: This requires both good practices and good tools.
5. Any necessary documentation that isn't self-generating should be part of the Definition of Done for each Product Backlog Item (PBI) and the iteration's Increment.

In Scrum, you should have demonstrable increments of work every iteration. This is often more valuable than dead trees, because it represents a potentially-shippable increment and something the stakeholders can see (and often touch).

Maximize the amount of work not done by eliminating unnecessary documentation, and focus on implementing the practices that reduce truly essential documentation tasks to manageable proportions.

Answer 2

FRD is a way to document (in a waterfall way) what the intended functional requirements are. This doesn't usually document actual implementation. Using agile methods, you can better communicate to non-technical staff what is actually being delivered. Here are some suggestions to allow for comprehensive documentation while staying agile and productive:

1. Have the technical writers be a part of the project team, creating technical and non-technical product documentation iteratively. You can add "product documentation completed" as acceptance criteria for your user stories. The official product documentation can be your living document.
2. Hold a pre-launch high level demo (via your product manager). This high level demo can help marketing, sales, and department managers understand what is being delivered. You could add this to your sprint review processes.
3. Add more in-depth internal training considerations to your launch delivery checklist so you can consider it for each sprint or release. You can flag epics or stories as requiring internal training and who should be responsible for performing the training.
4. Hold more detailed internal trainings (i.e., train the trainer) for interested internal stakeholders (such as customer support and trainers). Record these and have the video available for those who are interested to reference. Add a link of the video to your project reference documentation. The internal training can be very helpful to identify trends in questions that you may want to answer within the official product documentation.

Answer 3

Right off the bat I can think of 3 ways to communicate outcomes and requirements:

1. Invite Stakeholders to Sprint Review or maybe Daily Stand Up
2. Show Stakeholders your product's Information Radiators

3. Update the Product's wiki/Slack channel:

   • Have an overview of the Product's outcomes/KPI/requirements known from the start (with slides or any other documentation)

   • Focus overviews on delivering Value (gaining: $/user info/etc and reducing: costs) and share as needed

   • Have Team Members add additional detail and overviews of Features as the Product evolves and new info emerges

If Agile is new to your culture make sure that Stakeholder communication goes through the Product Owner and/or the Scrum Master. Those 2 roles will ensure the Dev Team is not derailed by outsiders.

Good luck!