User Stories Are Overrated

In a recent project where I collaborated with an agile coach, she insisted on filling the backlog with user stories only. According to her, every task that was not a user story had to be rephrased, or it meant that it did not carry any value. I think this doesn't make sense, let me explain why.

What Are User Stories?

I see User Stories as the stencils of product management. Just like a stencil allows you to paint the same pattern quickly, a User Story is a good way to capture user value without too much thinking. Just fill in the gaps:

As a [type of user] I want [some feature] so that [some reason].

User Stories aim to make sure that we take a user-centric approach to design. User Stories help us practice empathy by adding information about the user situation. We put ourselves in their shoes and focus on building features that let them achieve new tasks or relieve pain points. User Stories let us prioritize development work by what matters most for the users.

Where Do User Stories Fall Short?

As time goes by, and agility becomes mainstream, user stories transform from a helpful tool to a de facto standard everywhere. The term "User story" is now almost a synonym for "feature".

However, even though you can use the same tools as Bob Ross, a famous painter who taught millions of young Americans to paint beautiful landscapes, you probably won't paint happy little trees as well as he does.

Don't take the tool for a rule, user stories are only meant to capture user-oriented value. There are tons of changes you can make to an application that won't alter the user-perceived value, like for instance:

• adding analytics to measure user behavior
• refactoring for easier maintainability
• testing a UI change to improve transformation rates
• storing a log of events to conform to compliance rules
• improving a CPU intensive task to reduce hosting costs
• documenting obscure parts of the application
• training a new developer
• increasing test coverage on a sensitive procedure to avoid costly regressions
• etc.

These tasks do not fit in the user story template. Yet, they do bring some kind of value and need to be prioritized. So what can we do about them?

Value For The Business, But Not For The User

No agile methodology ever recommended having only user stories in the backlog.

• Extreme Programming, the origin of user stories, fills its iteration planning with user stories and failed acceptance tests.
• Scrum talks about features, functions, requirements, enhancements, and fixes
• Kanban abstracts it all with the term work item.

I think that the backlog should contain items that bring value to the business globally, no matter the form. Let's try to put a name on these other kinds of value.

Validated Learning

In the Lean Startup methodology, product owners imagine and run experiments to validate or invalidate hypotheses.

Say we want to learn if adding a social login would be of any use to our users.

We create an experiment by adding a social button to the login screen, and measuring if anyone clicks on it. Even if it brings the user to an error page, the experiment helps to figure out if the customers show interest, and if we should invest more or not.

This will help us estimate the user value of a future feature. But the experiment itself doesn't have any value for the end user - it just has business value. It helps to make informed decisions on where to invest.

Cost Reduction & Revenue Optimization

This is probably the easiest value to get a grasp on. Businesses exist for one main reason: making money.

If we had identified a way to cut our monthly cloud provider bill by half, and if an agile coach said: “You can't do that, it doesn't bring value to our customers”, we'd certainly be angry.

Reducing costs and increasing revenue do bring a lot of value from a business point of view.

Security

Often, new security breaches are discovered.

If our product uses one of the compromised libraries, it risks collapsing anytime. Products usually being at the heart of the business, everything is at risk, we have to fix it.

It does bring some kind of value to users as well, and we can create a user story from that:

As a merchant, I don't want the servers to go down so that I can still create my invoices.

It does work, but to me, this user story doesn't seem real. I don't picture one of the users actually saying this, it feels really artificial.

In worst cases, this might hide some part of the value because we're busier making our requirement fit the user story template than understanding the root cause of the problem. We could just say "Fix vulnerability by upgrading nodemon to latest version", and everyone would understand, without overthinking it.

Debt Repayment

We sometimes take shortcuts when developing new products. We choose to ignore some best practices to deliver faster. And that usually makes us contract some technical debt.

Even if we'd better continuously refactor, our debt might be so big that it needs its own backlog item.

It doesn't bring anything to the user, but paying debt now is cheaper than to keep paying interest for every new line of code.

Legal Requirements

Sometimes, backlog items are plain legal requirements we just have to handle.

For instance, most European FinTech startups must follow the Know Your Customer (KYC) and Anti-Money Laundering (AML) checklists. If they don't comply, their business just closes. Yet, it doesn't bring much value to the users.

We could still turn our brains around, and make such a requirement fit into the user story template, but it's ridiculous:

As anyone, I want people trading in financial markets to be well known by their platforms so that there is less risk of money laundering activities.

Being AML compliant is not about our users, nor innovation, nor learning. As is, it doesn't carry any value, but if we're not compliant, we risk paying huge penalties to the Financial Action Task Force and possibly be put out of business.

Conclusion

There should probably be more than just user stories in a backlog. A backlog is a prioritization tool using global business value as main input, instead of only considering user value.

Tip: And if you ever encounter an item in the backlog starting like "As a developer, I want ..." there's probably something wrong. The task to do might be necessary, but the modelization is wrong - that's not a User Story.

I'm not saying User Stories are bad, only that they shouldn't be used for everything, at the risk of confusing everyone. We should use them when and only when an item is supposed to add value to users.

While agility is the art of performing in an uncertain environment, it is evolving to a one-size-fits-all environment, be it with user stories, scrum or the Spotify model. I think we should be very careful not to consider tools for a methodology that works everywhere.

What would Mona Lisa look like if Leonardo had only used stencils?

In my opinion, it doesn't look as good as the original, same goes with a product built using only user stories.