An assumption is an unverified belief embedded in a proposed feature, deliverable, or requirement. Teams make assumptions visible by mapping relationships to business goals and defining metrics that can confirm or disprove them after delivery. section 4.3.5
Use assumptions to turn vague confidence into testable collaboration:
- Trace each deliverable to the business goal it is expected to influence. section 4.3.5
- State the belief explicitly, such as expecting social-media integration to make Frequent Flyer members post about their trips. section 4.3.5
- Attach an observable measure, such as the number of member posts generated after release. section 4.3.5
- Ask for concrete examples to expose incorrect interpretations of requirements before implementation. section 6.2 section 6.5.1
Testing a security assumption
A team might assume that a password is secure when it has eight characters, a digit, and punctuation. Concrete examples challenge that belief: “password1!” remains unacceptable because it uses a dictionary word, while longer random-looking passwords meet the stated security expectation more convincingly. section 6.2
Testing a booking assumption
A story about moving a London–New York flight from Monday to Wednesday appears straightforward when the ticket remains in the same price category. Asking what happens when prices differ or flights are full reveals assumptions and creates sharper requirements. section 6.5.1
Use the impact-map figure to inspect how proposed deliverables connect to an intended business impact and where assumptions require validation. section 4.3.5
