Requirements envisioning is the initial, high-level exploration of what needs to be built. It happens early in a project — before the first sprint — and its purpose is to understand the scope and nature of the problem, not to detail every feature.
Think of it as sketching the map, not writing the turn-by-turn directions.
What you’re trying to understand:
- Who are the stakeholders and users?
- What is the scope of the system? (What’s in, what’s out?)
- What are the high-level features and capabilities?
- What are the key quality attributes (performance, security, scalability)?
- What are the biggest risks and unknowns?
How to do it:
- Use lightweight techniques: user story mapping, personas, high-level use cases, context diagrams
- Involve diverse perspectives: business, technical, design, operations
- Timebox it — days, not weeks. You’re building understanding, not writing a spec.
- Accept that you’ll get things wrong. The purpose is “good enough to start,” not “complete and correct.”
Output: a prioritized, high-level backlog and enough shared understanding that the team can begin the first iteration with confidence.
The anti-pattern: spending months in requirements envisioning, trying to capture every detail before writing a line of code. At that point, you’re just doing waterfall with agile vocabulary.
Related: Architectural Envisioning, Sprint Modeling, Agile Requirements