Getting the user stories on the right size, in the right format, in essence getting to the sprint in a READY-READY form (READY actually means READY, not make-believe READY…) requires a lot of cooperation from the Product Owner/Manager. He should understand the value he gets if he INVESTs in stories/features, because it DOES create work that he’s not used to. In some cases you will have a hard time getting to this level of detail from your Product Management, so you’ll need to create a Product Owner that proxies and fills in the blanks – usually a Business Analyst, Designer, Architect can help in that aspect.
The biggest challenge is if a Product Owner/Manager doesn’t think he can get any business value from small granular stories, and that “he needs everything – all features, and all requirements in all stories”. In that case, your biggest impediment is that the PO doesn’t believe in Agility – and you should think what to do about that. I would suggest a discussion about Agile potential ROI for the business, driven by faster time to market, better adjustment to customer real requirements, and much better predictability and trust that the versions will get out on schedule.
On a side note, I see the lack of understanding/belief in the value of agility on the business side as a very common and very dangerous problem. Without the business side on board, the development teams will lose a lot of the reasoning behind some of the Agile practices/principles, which might lead to regression to lesser ways.
E.g. ROI for faster sprints without delivery to the customer or PO coming for a demo – I believe they still have value in having a fast feedback cycle, even if internal, and even if used mainly for the team improving its performance. But its clear that the ROI will be a lot smaller than if the sprint result is actually taken by the customer or other groups in the company, both to earn money, as well as give much better feedback.