Lots of people believe that in agile environment, requirements are not necessary, that is not true at least according to me.
The requirements in agile environment are represented as user stories, user stories helps the team to understand who the actual users are, what they want, what is to be developed and what should it look like when it is completed. The ability to write and understand user stories is the heart of agile development and everyone involve in this environment which includes developers, BA, testers and business users should have or learn this skill.
When writing an agile requirement try to answer the following questions “Who, Why, What and When”. Start with gathering high level user stories to describe the needs and goals of the stakeholders, this will help you to identify project goals and deliverables. Every user story created there onwards should one way or another add value to the high level user stories, the advantage of that process is that if you find any stories which do not contribute to the high level goal you should ask ‘Do we really need this?” or perhaps you have misinterpreted/misunderstood the user story.
For each user stories it is also very important to write the acceptance criteria which usually come from business users. This is very crucial during the QA and UAT phase, do not leave this for later, it is very important and the best time to do this is when user stories are created.
During gathering agile requirement focus more on ‘why’ and ‘what’, do not fall into the trap of ‘how’ which is very tempting especially if you have developers and architect in the meetings.
For each requirement define the scenario broken down by pre-condition, actions and expected behaviours.
All the user stories collected during various meetings will form your product backlog, later based on the prioritisation user stories will be added to the iteration backlog.
The biggest advantage of agile requirements is when you have product managers, business users and developers working together you get the best outcome in the shortest period of time.
Finally don’t be tempted to gather and define all the user stories in advance, all you need is the user stories for the current release, once you get to a stage of implementing a user story that is when more details are needed.Feel free to contact me if you have any questions, good luck with requirements gathering.