Your User Stories Suck

I have mixed feelings about User Stories. Not the structure, necessarily, but the idea that the end user is the only perspective that matters.
I feel this is distilled pretty well in User Stories, so I’ll use them as scapegoats here.

At a high level it’s pretty reasonable: focus on the user when defining a problem/need.

“As a [type of user], I want [some goal] so that [some reason].”

However, it’s not immediately clear how “we need to update the database” or “we are asking to get hacked” fit into this frame.
To be more specific, if a dev’s job is to take care of an iceberg worth of “shit that needs doing”, User Stories seem to only fit well for the exposed tip of the ordeal.
Plus, a user can want an infinite amount of features, including features that don’t fit well into the product.

What do we do with those other tasks? How can we stop the feature creep? Are user stories not fit for purpose?

User Stories

“User Stories are chunks of desired behavior of a software system.”
Martin Fowler¹

Sounds like a great way to ensure the team focuses on adding value to the product instead of tinkering endlessly with not-so-relevant parts of the system.

It seems particularly useful in the context of Lean Startups, or greenfield projects more broadly.
Especially in regard to build-measure-learn, where the assumption is that users will guide product direction through measured behavior and feedback.

That same approach kinda falls apart when you’re knee-deep in a legacy codebase or a mature product.
These systems are often full of past compromises (made to get to market fast) that now need attention, but The User doesn’t know or care about this.

So what’s the approach here? How do we make space for that work?

Dev Stories

You might try to create a somewhat separate backlog of “Dev Stories” to ensure technical stuff doesn’t get drowned out by shiny new features.
But how would that look like?

“As a developer, I want to fix known issues so that I don’t get emergency calls at 2 AM.”
“As a developer, I want a secure, up-to-date tech stack so that my job doesn’t suck as much.”

Doesn’t quite have the same ring to it, does it?

Jokes aside, this would mean juggling two separate backlogs, when one is already hard enough to keep at bay.

Also, how is your Product Owner/Manager/Analyst/Thing supposed to prioritize stuff they don’t even understand?
How important is keeping your server OS updated? Is it more urgent than the feature marketing wants by Friday?

It’s a hard sell without a clear link to user value.

The Temptation of More

The average user seems to want one tool to rule them all. Technically minded people (usually) know that to be a bad idea.
A tool that tries to do everything is often great at nothing, and since we (hopefully) want our products to be great, there is a conflict between what the users think they want and what is best for the product.

Add to that the constant marketing “necessity” to add flashy features to more easily sell the product, and you end up with a great recipe for feature creep.

This manifests as a near-infinite pile of User Stories that often begs the question: Who actually asked for this and why?

I think that question is pretty key.

Do we know what The User wants, or are we just guessing? Is marketing chasing trends or chasing value? Are we conflating The User with the marketing team?

Anecdotally, it’s hard for me to map this feature obsession with actual people using actual software.
100% of my non-tech friends and family have 0 interest in The Cool New Feature^TM and would much rather have any given software be better and faster at what it already does, than poorly perform new tricks on every update.

Do we actually know what percentage of our users want/need that new feature, or are we spending time and money chasing hunches?

Hierarchy of (Software) Needs

I find it useful to adapt Maslow’s pyramid to software, where each additional level only adds value if the previous one is in place.

In my mind, a software product should be:

1. Functional: It does what it should.
2. Reliable: It can be trusted to do so.
3. Usable: It’s accessible to non-tech users.
4. Secure: It protects user data and privacy.
5. Performant: It’s reasonably efficient.
6. Scalable: It adapts to reasonable increases in workload.
7. Delightful: Modern UI, quality-of-life features, polish, etc.

The point here isn’t to undervalue #7. It’s critically important.
But using a beautiful UI to entice a bunch of new users to use a service that can barely cope with the current ones makes no sense.
And showing off shiny new features when user data is simply not safe in the system due to poor security practices is not only disingenuous, but immoral.

The issue here is that the average user only seems to see tips #1, #3 and #7 of the iceberg.

Blind User Is Blind

Most users are too technically illiterate to ask for quality software.
But that desire exists, it’s just ‘hidden’ as a combination of implicit assumptions and unconscious expectations.

This is often visible after the fact: Once a service gets hacked and its users start getting spam calls all day, they care about security. If the software starts behaving subjectively “too slow”, they will complain. If the team takes too long to adapt to market changes due to horrible developer experience, they will leave.

By the time The User asks for security, reliability or scalability to be “added” to a system, it’s usually too late.
These are not things you add later, they must be built and designed into the system from the start and maintained constantly.
They can hardly be just bolted on.

However, I don’t think that makes User Stories unfit.
It’s just a matter of reading between the lines, surfacing implicit requirements instead of waiting for The User to manifest them.
These implicit needs should bubble up as any other item in the backlog.

“As a paying user, I want the system to scale well so that broad adoption doesn’t hinder my experience.”
“As a privacy-conscious user, I want my data protected, so future attacks don’t affect me even if successful.”

If these User Stories don’t fit in the backlog, that’s just the team not caring about their users.
At least not in those regards.

So What Do We Do?

It’s always good to question new features:

• For whom is it?
• How does it fit the system?
• What’s the cost to stability and maintainability?

Learn to say no.
More features is not “more better”.

I think we should, on one hand, expose those ‘hidden features’ as any other User Story, they are just as important if not more.
When raising a technical concern about the system, tie it to real user impact.

On the other hand, if you can’t do this, either try harder or admit there is no actual reason to be concerned. You might just want to improve something and that’s valid too.