Scope Hammering & Story Splitting
Making stories small enough to ship
Scope Hammering is the BMAD grooming technique for stories too large for a single AI session. The PM persona actively shrinks story scope to the minimum deliverable unit that still produces testable value.
A story is too large if it cannot be implemented and tested in a single AI session with a human review at the end. The right response is not to implement it across multiple sessions — it is to split it. Scope Hammering is the structured approach: the PM persona applies a minimum-viable-increment question to the story and extracts the smallest subset that delivers real value. The remainder becomes a new story, not a continuation of the current one.
The hammering question is: "What is the smallest piece of this story that would be worth shipping on its own?" That piece becomes story A. The complement becomes story B — but only if it is also worth shipping on its own. If it isn't, it is scope that shouldn't exist yet, and it goes back to the backlog for future prioritisation. Scope Hammering is not story slicing for its own sake. It is a discipline against building things that aren't needed yet.
Story splitting has a common failure mode: stories that look split but share an implicit dependency, such that story A cannot be merged without story B. If story A requires a data structure that story B will introduce, they are not actually separate. Scope Hammering catches this by requiring each story to produce a testable increment independently. If a story's output cannot be tested without another story's output existing, they need to be reconsidered as a unit.
Key Concepts
- Hammering question: "smallest piece worth shipping on its own?"
- Complement becomes a story only if it is also independently shippable
- Non-shippable complements go to the backlog, not into the current sprint
- Split stories must be independently testable — no hidden shared dependency
- Scope Hammering prevents building things that are not needed in this sprint