‘Placeholders for conversations’ are an outdated idea that is irrelevant to many developers. And anyway, not every developer wants constant conversations throughout a sprint.
Those who disagree are probably either 1) developers lucky enough to speak with their users regularly or 2) agile coaches who embody gold-standard best practices. Both are equally fine.
But what about all the developers in silver/bronze/cardboard quality teams? Being told what to do by their manager, working off tickets and documents, and just trying to get along without making too much of a fuss.
There’s no harm in striving for better, but equally, knowing the broad constraints of the system you are working in offers realistic expectations.
Why beat yourself up in retrospectives because you work off tickets, user stories or business requirements? Honestly, if that’s where your employer or line manager is at, then don’t feel bad about it. Do you really want to speak out like an agitator or change agent? Instead, you might be better off focusing on the here and now, and what’s in your immediate control.
Pay close attention to what regularly causes work to become blocked, work to take longer than expected, or users to complain about newly shipped features. Really dig into what’s going on here and then assess whether you are well-placed to address it. Being more agile might not be the solution.
If nothing else, take the time to review the requirements before developing them, and don’t hesitate to kick them back for clarification and more analysis if they really aren’t good enough. This one simple thing will drastically improve the quality of software being written.