Dear Experts.

I'm new to the Agile approach, I only had one small project using agile. I started to look into materials but I got confused by one fact and I hope if someone can help.

It says the requirements approach during agie is that you only care for the what you need for each sprint and you define the requirements for that sprint, which is fine. But for the development phase, we all know that user stories are not enough, so for you to "Define Requirements" for that sprint you basically will have no time to break down the user story into detailed functional requirement because to do this you need to go back to your stakeholders to define what they need exactly from that requirement, for both functional or nonfunctional.. 

The question here how will you find time to do those requirements definitions sessions when you are actually heading into a sprint? especially when you don't need to do requirements catalouge before the development in Agile like what you do in Waterfall.

I appreciate your opinions.

Madi

The user stories are the unit of work, but they exist in the context of systems and processes. If those processes and systems are relevant to the work, it is really up to the members of the team to request that level of definition. On the teams I manage, the definitely of ready (meaning the story is suitable to be worked on during a sprint), there are two points that must be followed.

• All user stories must have defined Acceptance Criteria using Gherkin Syntax (GIVEN, WHEN, THEN). This helps satisfy the "Testable" portion of the user story
• Any artifacts necessary for the full understanding of a user story (which can be decided by anybody on the team) must be included before it is considered ready. This means process flows, data models, prototypes, decision tables, etc.

If your team doesn't do these things now, they usually become easy to implement via quality team retrospectives. If the team identifies a problem and that problem comes from not doing any of the above (or other productive actions you've learned about), you simply recommend implementing them.

If you are concerned that you aren't delivering on your value as a business analyst then BA Roles & Responsibilities [Video] gives good clarity on what you should focus on, regardless of methodology or exact deliverables.