I started my career as a business analyst in a very waterfall organization and my deliverables were quite clear and defined as a part of the SDLC. The heavy hitter being the requirements document, business requirement document, requirements package, or whatever you might call it. The largest and established organization typically have a template to follow that includes where to include process, the attributes per requirement, etc.
In agile, the less document heavy development cycle, things are different. In my experience two primary activities of a business analyst in agile that actually provide value. First, is the keeper of the functionalities. Things will be changing all the time and user stories are not a great way to keep track of how an application works. Keeping track of the functionalities, business rules, etc provide a lot of value. Secondarily, I function as a conduit of communication and shared understanding. Whether it is by process models, meeting facilitation, user cases, or whatever, I constantly get to work my BA muscles to help drive to the best solutions.
For a longer and more visual explanation Business Analyst Deliverables Agile vs Waterfall
brought to you by enabling practitioners & organizations to achieve their goals using: