In 30 seconds
- Many requirements can't be known up front.
- They emerge from feedback, learning and changing needs.
- Agile backlogs are built to absorb them.
Why they happen
- Users don't know what they want until they see it
- Markets and regulations change
- Building reveals technical constraints and opportunities
How agile handles them
The Product Backlog is continuously refined and reordered. Short sprints and reviews invite feedback that surfaces new requirements while change is still cheap. It reflects the value of responding to change.
Keeping scope under control
- Hold a clear Product Goal to judge new items against
- Add new work only by ordering it against existing work
- Remove items that no longer serve the goal
Myth vs reality
Myth · Emergent requirements mean poor analysis.
Reality · Some things can only be learned by building.
Myth · Everything should emerge.
Reality · Some requirements, like regulations, are known up front.
Myth · New requirements always expand scope.
Reality · They often replace less valuable items.
FAQ
How do we explain this to stakeholders?
Show how early feedback avoids building the wrong thing.
Do contracts allow for it?
Agile contracts are designed to.
What's the risk?
Scope creep, if new items aren't ordered against a goal.