The problem with user stories is that it discourages team communication. It might seem like it encourages team communication, but it really doesn't. They are just another way to avoid talking-things-out and to have disconnected team members push tasks to another.
The core problem with user stories is that they are just words - and words are open for interpretation. It's a fundamentally broken technique; this is why there is so much writing (promotion) on 'how to write user stories'. When something works well and is intuitive, you don't have so many people 'doing it wrong' and needing to learn to do it right.
"It depends upon what the meaning of the word 'is' is"
Here's an example of the problem with user stories and how I fixed it:
When I used to write user stories with my team, my teammates would read them, think they understand them and then go on with their own interpretation of the story, which ended up being different than mine. I started noticing the problem was with the user stories, and not me, when different engineers would interpret the same story very differently.
So I did something different: I stopped writing them.
At first the engineers were confused, so they would come to me and mention the story was missing. Then something amazing would happen...we would talk about it! Sometimes, several of us would talk about it together. After a while everyone got into it, team collaboration took off and the product became better. We would talk about everything frequently. It wan't uncommon for my tech lead to lean over and ask questions like:
"Does it make sense to have X be above or below the body...?"
"What if instead we added this feature here and moved this over here...?"
"You know, I think we can make this text clickable, but we would have to make this slight alteration..."
We'd build the product side by side and through productive conflict, we'd end up with a better solution.
Define problems, not solutions
User stories also fall into the all too common trap of defining a solution (what to do) instead of presenting problems to the team. Take acceptance criteria for example. You can only have accurate acceptance criteria when you know how something is implemented.
The product scientist's job
As a product scientist, I am the research arm of the team. I look outwards, engage customers and experiment with the product so I can bring challenges to solve and goals to reach. I am at their disposal all the time and it's my job to make sure everyone understands what we're up against and we have the most information possible. All these nuances cannot be distilled into a brief paragraph of awkward formalities.