Making Agile Requirements Work-No. 2
The BABOK® says the purpose of eliciting requirements is to identify and understand the stakeholders needs and concerns, and understand the environment in which they work. This goes beyond documenting stated or superficial desires, it involves ensuring that the stakeholders actual underlying needs are understood. This is all great, but it is not useful if the requirements are elicited and documented in a way that a shared understanding is generated. Just getting the requirements documented and signed off on doesn’t help create the solution.
Failure to Establish a Shared Understanding
The myriad of stakeholders involved in an effort all have different perspectives. Their language, context, and intent are based on their particular experience. When my wife asks me to take out the trash she really means, “Talk out the trash right now, from every room in the house, replace the bags, and pick up any dirty laundry you find in the rooms you are in”. I didn’t share this understanding when we first got married. I do now – but it was more expensive than it would have been to take the time to get clarity on her context and intent. When requirements are elicited without establishing a basis of shared understanding of language, context, and intent there is the high likelihood that the requirements will be misinterpreted. This is particularly true when requirements are passed from stakeholder to business analyst to developer to quality assurance. This lack of common understanding and context often obscures the rationale for the requirement. When people don’t understand what they are doing and why they are doing it the potential for missing the mark is very high.
Establish a common language that communicates context and intent. This takes some time up front – but it is less expensive than the rework and delay associated with misunderstanding. Focus on context and intent more than detailed documentation. Verify the understanding of requirements between various stakeholders – not just a single sign-off. Clarify why each requirement is important in business language everyone agrees upon and can understand. Taking a minute to get clarity from my wife on intent would have resulted in a faster time to the desired outcome.
Tags: Agile, Business Analysis
[...] have proposed that Agile Requirements must be built at a purpose and outcome level, must leverage shared language that communicates context and intent, and must be based on a stable view of the domain. But even with these in place requirements can [...]
[...] that the way that requirements are captured should express the purpose and outcome, they should establish a shared language that communicates context and intent, is should be a stable view of the problem, and it should [...]
[...] Establish a Shared Language [...]