This question came to me from a senior engineer who worked in an environment where ‘User Story’ had become deeply synonymous with ‘developer task’. Here is how I answered.

Absolutely, 100% yes. Every one of them.

A User Story is not a development task.

It’s not a screen, an API endpoint, or a database column. Those are technical, “horizontal” slices of work. A User Story is a fully functional, “vertical” slice. Delivering it may involve working on one or more of those technical components.

Fig. 1: This is not a tasty burger.

Tasks and User Stories are both useful concepts. But conflating them causes harm to how we think about our work. And in software, “how we think about our work” is the ballgame.

A User Story is a tool for agility.

The correctness of the software you make is unknowable until you deliver it to the people who will use it. We have to be agile in our work to navigate this inherent unknowability.

We can be agile by building the next slice based on what we learn from shipping the previous slice. To work this way, we’ll need to have one or more high-fidelity conversations about each of those slices.

Writing a User Story is a way to start such a conversation.

(Here is a way more in-depth article from Tim Batty on making User Stories work for you and your team.)

Related Discussion:

We had an open discussion through our Industrial Logic TwitterSpace. Here is the recording of that conversation.