Uncertainty is incomplete and evolving knowledge about what users need and how a team should build it. At the start of a project, many unknowns remain; collective understanding grows as the team learns, but the path is neither linear nor predictable. section 1.2.3
Trying to eliminate uncertainty by locking down requirements early can preserve incorrect assumptions. A BDD team instead expects requirements and their interpretation to change, seeks early feedback from users and stakeholders, and changes direction when evidence demands it. section 1.2.3 section 2.3.3
Effective uncertainty management combines several practices:
- Prioritize features that deliver value, improve understanding of user needs, or clarify how a feature should be built and delivered. section 2.3.3
- Build and show a feature early when user reaction is the fastest way to test assumptions. section 2.3.3
- Break high-level features or Epics into User Stories so they become more manageable to implement and deliver. section 5.0
- Keep implementation options open instead of committing to a definitive solution before the team knows enough; this is the role of Real Options. section 5.0
- Use Deliberate Discovery to reduce project risk by addressing uncertainty and ignorance proactively. section 5.0
Testing an uncertain feature
Instead of specifying every requirement at the project’s beginning, a team prioritizes a valuable feature, builds an early version, shows it to users and stakeholders, and revises its direction from their feedback. section 2.3.3
Figure 1.4 At the start of a project, there are many unknowns. You reduce these unknowns as the project progresses, but not in a linear or very predictable way.
A figure showing many unknowns at project start and their reduction over time, emphasizing that learning does not follow a linear or predictable path. section 1.2.3
