A lot has been said and discussed about the challenges faced by Scrum teams to manage the expectations of product managers on their journey to build great products. Many product owners and ScrumMasters find that there is a lack of guidelines and tools available to effectively facilitate the requirements handshake between business and technical teams. There also can be challenges when dealing with version control requirements along with providing the history and traceability that are often a must-have.

There is a constant struggle between the product owners and Scrum teams to establish, at a granular level, the requirements and user stories. Typically, product owners are busy with outbound or operational activities, such as conducting customer demos, attending events, supporting sales activities, and collecting user feedback post implementation. 

Meanwhile, Scrum teams are involved in activities like designing, implementing, and releasing the user stories planned in their sprints. So, how do these parties meet and exchange thoughts over the requirements? How can the product owner be sure that the Scrum team has understood the requirements in its entirety and is on the right path for development? 

Product owners play the role of representing the customer. They should have a clear idea of what customer needs and expects. On the other hand, the Scrum team members come from a technical background and they should understand the technical intricacies of implementing a story. So, how do these two parties work together in harmony to provide the optimum solution to the customer? 

Here is where ScrumMaster comes into the picture. This person is responsible for ensuring that the Scrum team gets all inputs from the product owner. The ScrumMaster's real challenge is in implementing processes and best practices so that there is a constant flow of well-scoped, meaningful, well-prioritized user stories, from the product owner to the Scrum team. This is tricky business for the ScrumMaster who needs to communicate these user stories at a granular level, which are executable within a sprint.

Effective and painless agile requirements management begins with the product owner creating a simple story and passing it along to the Scrum team. The Scrum team then either comes back with queries around that story or a story point estimate. On obtaining clarification on all queries and after receiving development estimates, the product owner prioritizes the various stories. Further fragmentation of stories is advisable so that functional implementation of stories with higher business value can precede those of lower business value.

The ScrumMaster plays a crucial role in balancing the act of requirements management between the product owner and Scrum team. During this process the product owner focuses on delivering the following items. First, an elaboration of the product backlog, which includes identifying and clarifying the user stories. Next, this backlog of clearly identified user stories is passed to the Scrum team to provide estimates on delivering the aforementioned user stories. Thirdly, the product owner prioritizes the user stories, typically focusing on getting the more complex or significant (based on business value and customer expectations) user stories completed first. The end result is the creation of the product backlog.

Product and estimation backlogs can be well managed via Scrum boards, in which a filtered product backlog is available for sprint planning and estimation. However, if there is constant or frequent changing of requirements and feedback from customers (like in a help desk scenario), a kanban (or scrumban) board would be more appropriate as it allows for more freedom and flexibility within the workflow. 

It is critical to understand that the process of prioritizing requirements or subsequent user stories are driven by factors like ROI and the total effort and cost required for product completion. The fool-proof calculation of these two factors leads to an impeccable business value for every user story. This assists the product owner in prioritizing user stories more effectively and in inline with the goals of the organization and customer, resulting in a win-win situation.

But how can these backlogs of user stories, estimations, prioritization, and development progress all be tracked on a scrum board throughout the sprint?

Agile has an answer for this.

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.