There is a practice in many agile conversations known as having a “Definition of Ready” for a Product Backlog item. That is, a given User Story (or other PBI) must meet the Team’s “Definition of Ready” to be considered actionable or even worthy to estimate.
This can be desirable from the team’s perspective when they are not getting enough information about the work they are being asked to do by the Product Owner.
While I understand the desire for this from many teams perspective, this as a potential struggle between precision and self-organization. Lest we forget, backlog items are invitations to conversations in which many of the attributes are detailed in collaborative discussion.
I know that having a Definition of Ready works for many teams. No denying that I’ve seen it be effective to helping clarify ambiguity. This is just a caution that it can go too far in some cases if we trade flexibility for a mandatory checklist.
The Definition of Ready is a practice that I believe makes sense to understand and explain to any team struggling with lack of clarity in requirements, but I also believe it is a practice that a team can elect into, just as we choose Planning Poker vs. some other estimation technique.