planning — splitting and merging
Using INVEST against the map
INVEST is most useful when applied to a story whose shaping has produced real material. Looking at the wireframe states for "Gal marks an open-answer response," the team notices: there are six wireframe states. The basic mark, the two rubric variants, and three error conditions. The story is failing the Small test — six states is too many for one story.
Applying INVEST as a diagnostic, the team splits:
| Before | → | After — Story 1 | After — Story 2 |
|---|---|---|---|
| Gal marks an open-answer response | → | Gal marks an open-answer response (basic — no rubric) | Gal applies a published rubric to her marking |
The split is not arbitrary. Story 1 satisfies the walking skeleton — the basic mark is what release 1 needs. Story 2 is a release-2 enhancement. Splitting moves a card from release 1 to release 2, and the team adjusts the map. The walking skeleton stays intact. Release 1 is still shippable; it is now smaller, faster, and more honest.
The opposite happens too. Two backbones — "Gal sees the submission count" and "Gal sees the unmarked count" — turn out to need the same wireframe states and the same data shape. The Independent test fails — neither can ship without the other; they share their contract. The team merges them into one story: "Gal sees marking progress at a glance." The map loses one card and the work flows cleaner.
Merging is rarer than splitting, in our experience. Splitting is the more common move because shaping reveals stories to be larger than backbones suggested. INVEST is the lens that catches both before amigos starts.