the pull — when the chain arrives broken
When the chain arrives broken
The previous page describes the ideal: every artifact exists, every gate was passed upstream, the developer reads five complete documents and begins. Reality is less tidy. A story arrives with missing scenarios. The design isn't ready for this story yet. The domain language is unclear — two people use different words for the same thing. The brief was thin, and nobody noticed until the developer started reading.
The discipline is not "send it back upstream every time." That is idealistic, expensive, and will be quietly ignored — people will pull the story anyway and improvise. The discipline is: name the gap, record it, and decide.
Name the gap
Before pulling, the developer and PO check: which of the five artifacts are present and which are missing or thin? A missing scenario is a different problem than a missing wireframe state. A thin brief is a different problem than an unclear domain term. Name the specific gap — not "this isn't ready," but "this story has no scenario for the offline case" or "the error state for school-system-unavailable has no wireframe."
Record it
The gap becomes a note on the story card. Not a separate ticket — a visible note that says: "Pulled with gap: no scenario for offline submit. PO + dev to shape inline during implementation." This note is what the retrospective will trace when a bug surfaces in exactly this gap. Without the note, the gap is invisible and the retrospective has nothing to learn from.
Decide: shape inline or defer
Some gaps can be filled during implementation — a missing edge-case scenario that the developer and PO write together in 15 minutes. Some gaps cannot — a missing wireframe for a whole flow that the designer needs a day to produce. The decision: if the gap can be filled inline without slowing the story significantly, fill it. If it can't, the story goes back to shaping and a different story is pulled. The PO makes this call.
The cost of pulling a story with an unfilled gap is not just a bug — it is a trust deficit with the client who encounters a feature that half-works, a support team that fields questions nobody prepared them for, and a developer who has to redo work they thought was done. The cost of sending a story back is delay. Neither cost is zero. The PO's job is to choose the smaller one — and to track whether the team's gap rate is improving cycle over cycle, or getting worse.