INVEST

Something odd happened once the user story format spread. Every item on the board followed the "as a — I want — so that" shape, and half of them were still unusable. The format only fixes what a sentence looks like; it says nothing about what has to be inside it.

So planning kept stalling. Picking work for the cycle out of the product backlog — the ordered list of what might get built next — the team hit a line reading "as an admin, I want to manage permissions." Theo said he couldn't tell whether that was two days or three weeks. Nothing in the sentence said where permission management started or stopped, so Mia couldn't tell him either.

After a few weeks of this it became clear the problem wasn't any one sentence. There was no filter between writing a story and planning with it, so every unusable sentence made it all the way to the meeting before anyone noticed. INVEST is that filter: six questions a story has to survive before it goes on the list, asked early enough that the planning meeting never has to stop.

Take one story, ask the six questions behind the letters in order, and rewrite anything that comes back as a no. Each letter names a property the story should have.

1. Independent. It fails if the story can't start until another one finishes. Two items where A has to precede B can't be reordered, which shrinks your options every time you plan a cycle.
2. Negotiable. It fails if the solution is already nailed down. "Add a toggle in the top right of the settings screen" leaves nothing to discuss; "I don't want notifications on weekends" opens the question of whether a toggle or a quiet-hours schedule is the better answer.
3. Valuable. You should be able to say in one line what improves for a user or the business when this is done. "Add a database table" doesn't produce that line, which usually means it belongs inside another story rather than standing on its own.
4. Estimable. Ask whether the story is in a state where you can attach a story point, the relative size a team assigns to a piece of work. If a developer can't name a number, something is still unknown, and the investigation gets split off as its own item.
5. Small. It has to fit inside one sprint. "Checkout, all of it" isn't a story — it's an epic, a chunk that breaks into several stories.
6. Testable. Anyone should be able to judge whether it's finished and reach the same answer. "Make the screen easier to use" can't be judged; the written version of that judgment is the story's acceptance criteria.

In practice these six run during backlog grooming, the session where backlog items get cleaned up and reordered. Skimming the top of the list a few days before planning is enough. Teams don't run all six questions across the whole backlog, because items far down get reordered or dropped before anyone builds them.

The six questions pay for themselves at the front of the backlog on a team shipping user-facing work on a sprint cadence. New stories arrive every week, something has to be picked for the next cycle every time, and filtering early is cheapest there.

Where it works badly is just as clear.

1. Anything that isn't a feature tends to fail. Research-only work, a server migration, a bug fix — none of them answer Valuable in the language of a user. Don't force the standard onto them; track them as a different item type with its own rules instead.
2. Independence is never fully reached. You can't build an account page before login exists. The realistic goal isn't total independence but raising the share of items you can reorder.
3. Passing all six proves nothing about whether the story is worth building. The check looks at the shape of the sentence. It doesn't ask whether that feature should exist or whether now is the time. A quarter filled with stories that clear all six can still turn out to be wasted, and the check will not have warned anyone.

"This one fails the S. It won't finish in a sprint."

The item is too large for one cycle, so something has to come off it or it has to be cut in two.

"I can't get to T here. Tell me what counts as done."

Asking the person who wrote the story to spell out what counts as finished, because right now nobody could call it.

"I is never going to be clean anyway, so let's just fix the order and move on."

A proposal to stop chasing independence and settle for arranging the items in a workable order.

Pagedeck grooms the backlog on Thursday afternoons. Mia brings a dozen or so items likely to land in the next two cycles, and Theo runs the six questions on each one. Usually three or four of the dozen fail, and the reasons repeat: either the item is too large, or there's no way to judge when it's done.

Failed items get rewritten on the spot. "I want to manage permissions" split into "as a team admin, I need to change a member's role to viewer" and "I want to restrict who can invite members," with three lines of acceptance criteria under each. That took 30 minutes, but it's 30 minutes moved out of the planning meeting rather than 30 minutes added.

Plenty of people take INVEST for a writing format. You learn the story sentence and these six letters at the same time, so they end up filed together. But the format is the mold you write in and INVEST is the ruler you hold up afterward — in that order, write first, measure second. Mixing them produces requests like "please write this in INVEST format," and whoever receives that has no idea what's being asked.

The other frequent misread is treating all six as a gate the story must clear before it can enter the backlog. Six items in a row look like checkboxes, so the reading is understandable. But the point of the standard is to open a conversation, not to issue a verdict. Real backlogs contain items nobody can size yet and items that aren't independent. Make passing mandatory and the team starts editing sentences to pass, and work that genuinely can't be divided ends up as two stories that clear the bar while the work stays a single lump.