As a system, I want to…

by Aliaksandr Kosarau

What does a system want?

A long time ago in a galaxy far, far away, a girl named Sanita got a new job. For the first time in her life, she had become a business system analyst!

Her first project was the integration of several applications: data from one application flows to another, no manual copy-pasting is needed — isn’t this lovely?

The product backlog included lots of unusual user stories:

• As a system, I want to use data from Maps API, so that I can get the location of the user.
• As a system A, I want to communicate with system B via a RESTful API, so that I can exchange data.
• As a system A, I want to retrieve X via GET endpoint for system B, so that I have this data.

Sanita was confused about this “As a system” clause. How could a computer want something? What does this even mean?

*Back then, advanced AIs like chatGPT, Bing, Bard, etc hadn’t been invented yet.

Sanita’s senior colleagues told her that these were “technical stories” — just like a user story, but for more backend/technical features.

Design stories, legal stories

Later in her career, Sanita spotted many more “non-standard” stories, for example, so-called “design stories”. They looked just like regular ones, but focused on design changes, legal requirements, etc.

• As a user, I want to have a back button, so that I can go back.
• As a product designer, I want the website to follow a new design system, so that people like it.
• As a compliance specialist, I want our application to follow XYZ regulations, so it is compliant with this regulation.
• As a user, I want my Instagram account to be blocked, so that I am no longer able to post offensive comments.
• As an engineering manager, I want to use XYZ APIs, so we can win the “Best Tech Stack” award.

At some point, she found an entire Instagram account with such weird user stories. But why may they sound weird?

I want it just because I can

These stories may sound weird because of two things:

• They refer to an irrelevant consumer: a system, a manager, a designer, etc.
• Or the purpose is questionable: people like my feature, I am blocked, we win an award, etc.

So it is clear what needs to be done, but the justification is foggy.

How to improve it?

Tips for “fixing” user stories

See real users behind integrations and APIs

Try to focus on end-users instead of “the backend magic”. At the end of the day, if there are no users of the API — do we even need it then?

Consider more user classes

Maybe, your feature is actually not for your customers, but for:

• Content administrators
• Developers and testers
• Maintenance and support staff.

The Onion framework for stakeholder identification can help you in finding these other consumer categories.

When you identify the target audience properly, it often starts making sense.

Customize the format

Sometimes, user stories are just a standard in your workplace. There can be a better form to express a requirement, but you still wrap it into a user story in order to follow this standard.

As the author of this article, I am encouraging you to challenge this. Try more custom formats, with the purpose and the value explained more clearly.

• To follow the GDPR, there must be a popup asking for consent to use cookies.
• As returning to the previous step is possible, there must be a back button.
• Within the global UI components update, the popup must follow the new style (as per the mockup attached).
• To promote our premium subscription, the “Buy premium” banner must be shown after every ad.
• To decrease the customer service load, a user mast pass a troubleshooter before redirecting to a human agent.
• To decrease the server load, the user must be able to load data for 7 days maximum.

Pro tip: if this can scare your colleagues or managers, you can still call it “a story” and follow the standard process for “stories”.

Why it matters?

If your “who” and “why” are not accurate, this can impact the whole final product.

• Low-priority features can mistakenly go to the top of the backlog.
• UAT will be conducted with irrelevant participants and scenarios.
• Supporting documentation and FAQ will be unhelpful.
• The entire feature/app will not meet consumers’ needs or expectations.

I am calling you to be brave and fight for better requirements! It is always better to change requirements before than to fix the software after.

Have you ever faced such “technical stories” or “design stories”? How do you work with that kind of tasks? Let us know in the comments!