The Story of My User Stories

I knew a few things before I started writing user stories:

• Their use-cases are multiple — they can be the entry point for product scope discussions, design specifications, technical deep-dives, quality test plans, future documentation, etc
• Their readers can be anyone cross-teams — both technical and non-technical, and they are specialists in their areas
• They should define the what, not the how — eg: a frame needs to be hanged on a wall, let’s leave to the specialists to see if it’s being glued, nailed or anything else
• Their language should be commonly understood and technicalities are undesirable — anything specific to a reader or use-case will be noise for another reader or use-case (and noise brings risks as we know)
• They should follow the user angle — thinking as a user helps to better understand and communicate their wants and needs

I had some idea of how to execute them as well. As a, I want/need to, So that was already a fairly spread format, at least when it comes to providing context. I’ve heard something about acceptance criteria as well.
Acceptance criteria are meant to complement the narrative by describing the conditions that have to be fulfilled so that the story is done. It makes it testable and ensures that a certain story has the necessary to be delivered to users.

Ok context and acceptance criteria, easy!

1st iteration

I needed to specify a sign-in requirement.
A sign-in form can have multiple shapes and security criteria, but let’s imagine it’s about the classical email and password.

Let’s try this.

How did this story go? Here’s some feedback from my current self:

• Why does the user need to sign in to enter the app?
• The first acceptance criteria are too instructive. It’s not useful for most user stories use-cases.
• The two critical scenarios were included, yay!
• But there are other missing scenarios.

2nd iteration

Ok, it’s a few months later. Let’s try this again.

How did this story go? Here’s some feedback from my current self:

• Why is the user in the third person in the acceptance criteria? Isn’t this suppose to be the users’ point of view?
• The sentence structure of the acceptance criteria does not follow any rule. Didn’t I know that coherence makes it easier to read and understand?
• But nice use of a nested list! A better way of organising information is yet to be invented.

3rd iteration

Another few months later, I’ve heard about Gherkin — a language for describing behaviours to be used in automated tests and documentation, and why not user stories. Given, when, then is the formula, easy-peasy.

Let’s try this again.

How did this story go? Here some feedback from my current self:

• Big win! My OCD is not so hurt on this one. The whole text reads a story and repeated keywords help to keep the logic on point.
• The sense of hierarchy was lost. If I need to add extra details to the story, how can I do it while keeping it contextualised and easy to navigate?
• This long format, without an easy navigation system, might scare readers away. Trust me, I tested it, it happened.

4th iteration

Gherkin with nested lists and with the added detail that I’m now more aware of — it sounds like a good idea.

Fast-forward to today, let’s try this one more time.

How did this story go? Give me some feedback :)