Its all about capturing and understanding requirements. Requirements stem directly from customer needs and expectations. Product Owners, Scrum Master & the Scrum team need to understand, communicate, and deliver on requirements in order to meet customer demands.
Yes! Agile speaks about frequent releases and iterations. Flexibility to change scope and direction swiftly based on customer feedback and volatile market conditions. But achieving this desired agility doesn’t simply translate using scrum boards, but rather, it refers to a comprehensive discipline that brings about a dynamic process of terms capturing requirements, setting priorities, and delivering the product. Agile implemented effectively, will ensure that the customer’s voice is clearly understood throughout the project resulting in maximum customer satisfaction.
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. Investigations on this matter have revealed a significant obstacle particularly regarding requirements, more specifically, the lack of guidelines and tools to effectively facilitate the requirements handshake between business and technical teams.
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 out bound 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 such as 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 is a technical pool who 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 Scrum Master comes into the picture. He/she is responsible for ensuring that the Scrum Team gets all inputs from Product Owner. The Scrum Master’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 Product Owner to Scrum Team. This is tricky business for the Scrum Master who needs to communicate these user stories at a granular level which are executable within a sprint.
Effective and painless agile requirements management will begin with the Product Owner creating a simple story and sending it to development team. The development team will 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 will prioritize 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.
So now as we have been taking about the Scrum Master being the crucial point in balancing the act of requirement management between Product Owner and Scrum Team in the process of development, what are the key activities he/ she has to concentrate on?
- Elaboration of Backlog – For Product Owners to elaborate, break or clarify user stories.
- Estimation of Backlog – For Scrum Team, containing well defined user stories awaiting to be estimated.
- Prioritization of Backlog – For Product Owners, well defined user stories, that are already estimated by development team and are in pipeline to be prioritized.
- Creation of Product Backlog – For Scrum Team, packed with well defined user stories, estimated by the development team and prioritized by Product Owner (based on customer expectations & Business values)
Product and estimation backlogs can be well managed via Scrum boards, where a filtered product backlog is available for sprint planning and estimation. However, if there is constant or frequent changing of requirements/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/ 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. A win-win situation.
But how can these backlogs of user stories, estimations, prioritization and development progress all be tracked one a scrum board throughout the sprint?
Too many tickets, too many deliverables, leads to chaos and confusion
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 will be included on the board. These stories will be start from the “to do” column of your scrum board. A user stories with the highest priority in the backlog will be 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, and 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 your development team focused on only those items to be shipped during a particular sprint.
A well maintained Scrum board, simplicity leading to success!
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 which typically shall 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.
There are times when we follow all the above – well defined stories, well-estimated, appropriately prioritized, develop and they meet the acceptance criteria as well. But when we approach the customer with the final product, there still remains a discrepancy between what customer expected and what was delivered. Either you end up modifying the story, adding more stories or retiring 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 Scrum Master misses out on understanding and conveying the appropriate user stories to Scrum team, or may be Scrum team failing to deliver what was expected, all these lead to one thing – and that is Rework!
This typically would happen if we keep the rigid approach towards the requirements from the customer.
The heart of “agile”, is around frequent releases and iterations, the ability to change scope and direction rapidly in response to customer feedback, changing climates, and other unforeseen obstacles. The demand of lot more control of Agile over what code gets into the system arises.
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 requirement gathering stage to development and test stages including all the intermediate stages – Investigation, Feasibility and Design respectively.
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. One that allows Scrum teams to understand and develop the product efficiently. An agile approach to requirements management implemented correctly, will surely lead to fulfilled customer expectations.
