Agile encourages developing early and delivering early. At the start of a sprint only the user stories that will undergo development is included on the board. These stories start from the "to-do" column of your scrum board. A user stories with the highest priority in the backlog is the first to be included in the sprint. At the culmination of the sprint there should be some form of a "shippable" product. Following the end of the sprint and retrospectives are conducted, the next batch of users stories are gathered from the backlog and loaded into the sprint. This process repeats itself until all user stories from the product backlog are completed. This keeps your scrum board, free from clutter, and leaves your development team focused on only those items to be shipped during a particular sprint.
Agile believes in keeping things simple. Now, if we want to tie test management to this approach all we do is add a step to elaborate "acceptance criteria" for a story that typically should be done before estimation. A new backlog is created for product owner or test engineer to add acceptance criteria for elaborated story. If in your organization acceptance criteria is added by product owner himself, then you may consider adding this on the product owner's kanban board discussed above.
It’s often that we strive to follow all of the above: well-defined stories that are well-estimated, appropriately prioritized, developed, and meet the acceptance criteria. But when we approach the customer with the final product, there still remains a discrepancy between what the customer expected and what was delivered. Either you end up modifying the story and add more stories or you retire the story you implemented; the result is a pile of rework. And, no doubt, rework comes at a significant cost to the organization.
Product owners failing to understand customer requirements or ScrumMaster miss out on understanding and conveying the appropriate user stories to Scrum team. Or, it may be that the Scrum team fails to deliver what was expected. Regardless, all these lead to one thing: rework.
This typically would happen if we keep the rigid approach towards the requirements from the customer.
The heart of "agile" is centered on frequent releases and continuous iterations, the ability to change scope and direction rapidly in response to customer feedback, changing climates, and planning for other unforeseen obstacles. The demand of a lot more control of agile over what code gets into the system arises.
The roots of traceability of requirements are in the version control a product owner implements on the requirements. While there may be questions arising around the necessity of version control of the requirements, given the scenarios where requirements change at tremendous pace, we cannot afford to dismiss the older versions and concentrate on the latest. Skillful version control means that integration is never a headache, because your work reflects only a slight divergence from the original requirements. If the team members must regularly deal with small-scale divergences, they never have to deal with truly scary ones. You need traceability from each requirement or user story all the way to code change set, so that if required you are able to pull out or remove a given story all together.
Requirements management is a continuous process that includes stages such as requirements capturing, analyzing, tracing, prioritizing, estimating, and approving. This process extends itself from the requirements-gathering stage to the development and test stages including all the intermediate stages, investigation, feasibility, and design, respectively. With such a massive span of this, version controlling of the requirements becomes a mandate. So when we look at the entire application life cycle management (ALM), we understand that "requirements management" occupies a larger amount of ALM, and hence needs to be handled with care and utmost proficiency.
Using the agile methodology in its true essence, we can ensure that the requirement management process spreads across the entire development process. Agile practices promote a healthy relationship between product owners, customer requirements, and Scrum teams; these practices allow Scrum teams to understand and develop the product efficiently. An agile approach to requirements management that is implemented correctly will surely lead to fulfilled customer expectations.