Eliminating Agile Requirements Ambiguity
One of the many myths regarding Agile software development is that documentation is not needed. People may live by the that one of the core values in the Agile Manifesto is “Working Software over Comprehensive Documentation.” But does “over” equal zero? The goal is to have artifacts (working software) that add value and thus, creates an aversion to documentation. However, this aversion to documentation, we believe, stems from the CMMI type of documentation that can be a headache.
Getting back to requirements, and in particular, Agile requirements, we know that Scrum teams work from the product backlog. But the product backlog also needs to have an input (requirements). The objective is to make sure that each sprint and its work items are clearly articulated for what will be built and what will be the exit or “done” criteria for quality. This means requirements need to be organized and communicated in a clear manner in accordance with the Agile Manifesto.
Doing this requires special attention to ambiguity. Ambiguous requirements can lead to multiple readers (developers) with multiple interpretations that lead to mistakes and confusion. Proposed are requirements clarity characteristics to help you evaluate requirements in a systematic way that eliminates ambiguity, with the ultimate goal of improvement.
-
- Positiveness: The degree to which the requirement description uses inclusive definitions, rather than exclusion, and avoids negative statements.
- Positive: Users can only have 2 accounts.
- Negative: Users with more than 2 accounts should not be allowed.
- Boundary Clarity: The degree to which the requirement description states endpoints that do not duplicate number ranges with clear inclusion and exclusion descriptions.
- Clear Boundary: If bank balance is less than or equal to $100, charge $5 administrative fee. If bank balance is greater than $100, charge $0 in fees.
- Unclear Boundary: If bank balance if less than $100, charge $5 administrative fee. If bank balance is greater than $100, charge $0 in fees.
- Pronoun Usage Clarity: The degree to which the requirement description includes antecedent for pronouns such that meaning is clearly understood.
- Examples include: their, it, this, and that
- Adverbs Exclusion: The degree to which the requirement description excludes adverbs that can lead to unexpected and multiple interpretations.
- Examples include: generally, reasonably and mostly. How do you know if this requirement is fulfilled? For instance: Balances below $100 generally incur a $5 administrative fee.
- Positiveness: The degree to which the requirement description uses inclusive definitions, rather than exclusion, and avoids negative statements.
These are just a few attributes that can be used to effectively inspect and evaluate Agile requirements (or any requirements for that matter). Not only will they remove ambiguity, but they’ll also prevent many headaches and rework.