I didn’t in any way suggest anything even resembling “not a user story, not my job”.

And I don’t believe that Luís intended to suggest that purely technical descriptions of planned work are never appropriate. His article differentiated between stories and purely technical tasks, for example.

But purely technical descriptions of planned work, i.e. “engineering directives” simply are not user stories.

Now, different teams handle bugs in very different ways, but some of the tools at our disposal include “Bug” type Jira Issues (as opposed to “Story” type Jira Issues) and even different Agile processes that may be better suited to analysis and bug fixing. Continuous Agile processes like Kanban seem well suited for bug fixing, as opposed to iterative processes like Scrum.

Even during development, purely technical work is often necessary, and “Task” or “SubTask” type Jira Issues (as opposed to “Story” type Jira Issues) exist to describe this work. Often, as the team reads, considers, and discusses a user-centered user story, technical implementation details emerge and should be captured. SubTasks that are added to the Story Issue are a great way to capture the technical details that are implicit in and necessary for successful delivery of the user story.

My point is that user stories are not the only tool at our disposal, and choosing the right tool for the job at hand is one of the things that sets skilled professionals apart from amateurs.

Using the chosen tool correctly once selected is another mark of a skilled professional, and so I continue to assert that user stories (not bug reports or technical tasks) should always be written from the perspective of the user who will utilize and benefit from the business capability described in and specified by the user story.