Your User Stories Read Like Tax Forms
Most user stories are not stories at all. They can go two ways, from what i’ve seen:
either they’re technical requirements shoved into a mandatory template. “As a user, i want to…so that….”. Bleah!
or they are completely non-sense nobody understands because the Product owner didn’t take the time to understand what the user wants.
This is because we’re writing for Jira and KPIs instead of writing for a human being. We lose the narrative, and when we do, we build products that lack purpose. We build products for the sake of building, not to solve a problem or a need. And doing so, we create silo teams. Alone. Empty.
Writing a good user story requires two things: The structural discipline nof Mike Cohn’s “3 Cs” and the empathy taugh by Ann Handley in Everybody writes. Here is how to stop writing tickets and start writing actual stories that count.
The card is an invitation, not a contract
Mike Cohn established that a user story is built on three Cs: Card, conversation, confirmation. The card (the written text, the item in your backlog) is just a placeholder. Its entire job is to provoke conversation between the developers, product owner and users.
Single Source of Truth (SSOT) vs. The Intent of the Story
If your story contains the database architecture or API endpoints, you’ve stopped telling a story and started dictating a contract. Instead, try keeping the story, the need, the human interraction - in the User story (or post-it, for that matter).
TIP: Treat the user story like a book cover. The cover tells you what the book is about and why you should care. The Table of contents, like the links to Swagger, technical docs etc. tell you where to find the data. Don’t try to print the whole book on the cover.
Ditch the “user”
Ann Handley’s golden rule of writing is to place the reader - in our case, the customer - at the center of the narrative. “As a user” is just corporate fluff. It means nothing. It’s way too general and already filtered out by most people that read user stories these days. Do you remember that video where you had to count how many times a basketball was passed and in the background was a gorilla meandering by and you did not see it? “As a user” is the gorilla.
Give the person a pulse.
“As a frustrated accountant rushing to close the month” or “As a first-time mobile shopper” or “As a grandma that doesn’t see shit” sounds much better. If you cannot picture the human being who needs this feature, you cannot write a story that matters.
The “So that” is the only part that really matters
The template is simple: “As a [who], i want [what] so that [why]. Plenty of people rush through the “what” to get to the why. But actually the “So that” is the engine of the story. The value proposition, if you will. If this part is not describing how it’s going to improve the life of a user in a specific way, the story is incomplete.
TIP: Look at your backlog today. Find a story that ends with something like “so that the system updates”. Rewrite that “So that” to focus entirely on the human relief or benefit the feature creates.
Good writing is good thinking. When you write clear, empathetic stories, you build clear, empathetic products. Stop filling in templates and start telling the story of how you are going to make someone’s day better. Isn’t this why we’re alive? To make others’ lifes better, faster, stronger? Not harder, no. Just the other three.
