User stories and acceptance criteria that don't lie

The standard user story format —

— is a scaffold for a conversation, not the deliverable itself. Ron Jeffries, one of the format's originators, described the story card as standing for "Card, Conversation, Confirmation" — the card is a placeholder that reminds the team to have a real conversation about what's needed, not a specification that replaces that conversation. A team that writes a grammatically correct story and treats the format itself as "done" has skipped the part that actually mattered.

A widely-used checklist (coined by Bill Wake) for whether a story is actually well-formed:

Acceptance criteria are the specific, testable conditions that must be true for a story to be considered done — and they're what turns "I want to log in" from a vague aspiration into something a team can build and a reviewer can objectively verify, rather than argue about after the fact.

A weak story:

The same story with real acceptance criteria:

Every one of these criteria is something a developer can build directly against and a reviewer can check off objectively — no argument about whether "log in" was actually delivered, because "delivered" has a concrete, agreed-upon meaning stated up front, not decided retroactively when someone disagrees.

Especially for criteria involving specific scenarios or edge cases, the Gherkin style (Given/When/Then) makes the structure explicit:

This format is popular specifically because it maps cleanly onto both a plain-English acceptance criterion a Product Owner can read and approve, and an automated test scenario a QA engineer or developer can write directly from — the same sentence serves as the spec and (often nearly verbatim) as the test.

A story that fails "Small" or "Estimable" usually needs splitting, and the common trap is splitting by technical layer instead of by user-visible slice:

The bad split produces two stories where neither, on its own, gives a user anything usable — the API alone does nothing without the UI, and vice versa. The good split produces a sequence of genuinely shippable increments, each one delivering real (if incremental) value, which is the entire reason INVEST asks for "Valuable" and "Independent" in the first place.