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
Hi Madi,
Great question! Agile teams or scrum teams generally have two special roles: Srum Master and Product Owner.
It is the responsibility of the product owner to represent the customer/stakeholders. the PO will connect with the customer to understand the requirements and needs and, at the same time, supports the agile team to deliver value. When grooming stories and the next level of requirements detail is needed, the product owner provides those details based on their understanding of the customers and stakeholders by interacting with the customers and stakeholders.
Adrian
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.
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.
brought to you by enabling practitioners & organizations to achieve their goals using: