I see developers lose connection with the users, iteration momentum, urge to push feature etc. They get more focused on solving tasks than solving business need.
On the other side the users loose the feeling of impact and ownership of the change. After a while they don’t want to participate in another user study.
I came from a place where we released small features in days, got user freed back and changes again. Using data to guide every decision.
When looking back the “data” way gave way more business value, but the “user story” way was easier for management to see as tangible work.
Are we doing user stories the wrong way?
A particularly toxic practice is gating the creation of tickets in the ticket system to being only things that can be expressed as user stories or that "specifically have to benefit the user."
I worked at one place where I (as a heads-down coder) put more tickets into JIRA than anyone else, partly because the person designated as the "project lead" never put in tickets.
I got bitched out for writing bugs like "The build process takes 45 minutes" and was asked "How does that benefit the user?" and replied "the user would have had the product six months ago if we had a 10 minute build process".
To articulate it, the system itself has needs that must be advocated for. For instance, everyone accepts that the server has to be plugged into the electrical socket, that the system has needs from a hardware perspective too. The system has software needs that also must be attended to so it can take care of the users.
A better way to think about it is that the system has (1) framework and infrastructure and (2) a bunch of user needs that is satisfies. Good architecture by definition is having (1) properly designed to make (2) easy.