Are You Sure You Know What a User story Is? what stories really are.

A user story is not simply a task that follows the “As a… I need…” format, nor is it a Jira/Shortcut/ClickUp or whatever ticket.

The concept of a user story has been frequently misinterpreted, both historically and at present.

I believe that one issue with user stories stems from the misconception that Agile teams must present their work in story format, leading some teams to force their work into a narrative structure instead of focusing on the user’s needs. This can occur when teams attempt to transition from a traditional waterfall approach to the Agile mindset.

It is essential that user stories prioritize delivering value for the user, rather than merely accomplishing technical tasks. Technical tasks are not the source of user stories. It must be kept in mind that not all work warrants inclusion in a user story. Your assigned duties are distinct from the user story, as it is solely your responsibility to carry out the task, not the user’s.

The point of a user story is NOT to define your work. A backlog is NOT a list of things to do. A user story describes your users/customers working on things that are valuable to them. The whole point is to identify ways to make our customer’s lives better. Those are the things that are worth expending effort on. We decide what to do by identifying what our user/customer needs us to do to make their lives better. If you turn your backlog into a to-do list of technical tasks, you lose all of that.

In the realm of work, there exist two types: value-adding work that is appreciated by the user, and other work that you personally think holds value. The secret lies in striking a balance between the two. If you devote too much time to the latter, the risk of losing your clientele increases, potentially causing your business to flounder. Consequently, it is vital to make wise decisions regarding the work you undertake.

“technical user story” doesn’t actually exist

It’s important to note that a “technical user story” doesn’t actually exist. A user story should be based on what your user communicates to you. It should depict your user’s work, not yours. The term “story” shouldn’t be interpreted as referring to “any random programmer task”. Technical aspects are merely implementation details that support a story, rather than being a story in themselves.

A technical user story is overhead. Calling it “overhead” emphasizes its revenue-negative impact and provides the proper perspective. User stories should describe a specific task that a person in a certain role completes to achieve a beneficial outcome within a domain in your business.

For example, Login is not a user story. Period. No user has ever logged in, thought they’d accomplished something valuable just by logging in, then logged out.

Let’s see a small trick when you hear something similar to “I need to create a report”. The first question to ask is:

What exactly are your users going to do with the “data” in that report?

Simply presenting raw data is rarely useful. If your users use your report to do something, that “something” is your story, not the report generation.‍

“As a manager, I can print a pie chart showing tickets broken down by engineer, so that I can quickly tell if any engineers are overloaded”

That’s not really a user story as it focuses on a solution rather than a problem. If the issue is determining whether the engineers are overburdened, a pie chart of tickets may not suffice. User stories should address problems, and the process involves iterative exploration toward an ideal solution.

One way to try to avoid this problem is to shuffle around the extra-format thinking: In order to provide <this outcome that’s valuable in the domain>, <someone in role X> does <this work in the domain>.

“As a checking account holder, I want to deposit a check from my mobile device, so that I don’t have to waste time going to the bank”

“As a checking account holder, I want to save my credentials, so that I don’t have to input my username and password each time I log in”

“As a user, I want to invite my friends, so we can enjoy this service together”

“As a manager, I want to be able to understand my colleagues’ progress, so I can better report our successes and failures”

‍

Another interesting point worth mentioning is:

- You are not the user.

- The PO/PM is not the user.

- The CEO is certainly not the user.

The user is the user. A user story is the user’s story. A user story is just that — a story of the user at work.

The human species thinks in metaphors and learns through stories. Mary Catherine Bateson

If you are interested, I offer workshops for both product managers and developers. In these workshops, you will learn how to capture, refine, split, and manage user stories, as well as how to collaborate to turn those stories into working code.