No one knows what a User Story is anymore

Not a day goes by without me reading User Stories like:

As a user, I want to connect to the database So that I’m connected to the database.

If you’re the one responsible for this blunder, stop beating yourself up; you’ll be granted a free pardon at the end of this article.

A User Story must add value for the user

Of course, these lines aren’t a User Story at all. They look like one (“As a user, I want to… so that I…”), but you can’t judge a book by its cover. Unless you and your colleagues are specifically developing a database management tool, keep in mind that no user wants to connect to your database 🥲

No, Frank wants to book his train ticket to visit his Aunt Danielle, Mélanie wants to buy new running shoes for her next 10K, and I want to write my article. All of these actions require storing information at some point, but neither Frank, nor Mélanie, nor I have any use for your database.

Therefore, a User Story must absolutely provide value to your users.

As it stands, this is actually a task: something to be done at a certain point in development. You might ask, why not just write tasks? Or why not specify and develop features directly? These are all questions we need to ask ourselves to truly understand what a User Story is.

Let’s take a step back.

Why break your work down into smaller parts?

The problem with features is that they’re often way too big. Developing them takes days, or even entire weeks, of work. This is problematic:

1. You run the risk of developing things that are useless or low-priority. What you want is to deploy as soon as possible to get user feedback and adjust course if necessary. Sure, good user research minimizes the risk, but real-world feedback in production is the ultimate judge. This consideration is at the heart of Agile.

2. You’re setting yourself up for serious tunnel vision: until everything is done, it’s as if nothing has been done. If, for whatever reason, you absolutely have to go live tomorrow, it’s impossible. Why? Because your back end is perfect (a neatly isolated domain, a well-designed REST API), but there’s no front end (*).

3. There’s too much to do; developing everything at once isn’t an option. Mr. Descartes said much the same thing in his Discourse on the Method. It applies to Agile, it applies to Test-Driven Development, it applies to everything. René was quite the thinker, and four centuries ahead of his time, no less.

Users couldn’t care less about your User Stories

When you really think about it, the user couldn’t care less about your User Stories. They only know their job to be done and would, in principle, be very happy if you delivered features to them. User Stories exist because you, the development team, need to break down your work. Not into tasks, but into User Stories, because tasks aren’t usable in production.

How far should you break things down? Let’s keep it simple: if you can break it down, do it. That way, you’ll end up with atoms. Even if it means developing two or three of them in a row.

Come on, general amnesty for all, and… let’s just get to it!

(*) And no, I know what you’re thinking: no normal user is going to query your API directly.