Most topics surrounding the establishment of requirements revolve around how to write them (including my recent article entitled User Story Writing Starter Kit). However, not enough is written about the key ingredient of a robust requirements process. Some will say that when you document the requirement, you are done with the requirements process. I content, that this is just the beginning. The real value of a requirements process is not just writing it down, it is to begin the collaborative discussion.
In an Agile world writing down a requirement begins the discussion between the business and engineering side. Whether this is between the Product Owner and Development team or the Customer and Programmer/Tester, the importance is that a shared understanding begins. This discussion initiates the learning amongst the business and engineering side where the engineering side more thoroughly understands the business value of the requirement and the business side better understands the technical options of the requirement.
It goes much deeper than this. In the old world, there is a typically only a one or few folks who attempt to capture the whole requirement in a documented form. This forms the basis for a requirement specification that may get ‘thrown over the wall’ to development.
I would suggest a much more robust approach starts with writing down the requirement and then continues with the fleshing-out of the requirement in a collaborative manner with the whole team. This utilizes the brainpower of the whole team whereby each member may contribute to the understanding of the requirement and how to best provide a working solution for that requirement.
From a process perspective, the discussion first begins when the requirement gets introduced by the Product Owner to the Development team. As an example, this could be in a grooming, refinement, agile release planning, or sprint planning (depending on your approach) where the highest priority requirements are discussed and fleshed-out with the team’s input. During this session, the collaborative discussion may focus on the following:
- Understanding why it is a high priority
- Validating/updating the User Story is in Canonical Form (or defined form)
- Understanding the business value and customer perspective
- Describing acceptance criteria
- Considering high-level technical details
- Identifying unknowns and risks (each should have an action to investigate and mitigate)
- Identifying what is out of scope
- Identifying dependencies
- Decomposing epic to user stories or each user story to tasks
- Providing high-level sizing (e.g., t-shirt sizing, story points, etc.)
As the collaborative discussion ensues (usually in a time-boxed manner), the requirement gains more clarity and robustness, where there is a team understanding of the work. As details are discussed, the Scrum Master, Product Owner, or anyone on the team, captures the details within the requirement. At some point, the Product Owner and team will decide that it is ready to go into the sprint or work queue. There is no ‘throw it over the wall’ to folks who have little understanding or context of the requirements. Instead, when it is time to build, the developer and tester are fully aware of the requirement since they have collaboratively provided input into it.
Whether you work in a more traditional world or an Agile world, consider adapting to a more collaborative requirements discussion approach. Gaining the brainpower of the team and moving to a pattern of learning can achieve a much better understanding of the customer need and ultimately a better solution for the customer.
