I have learned an important lesson from my combined experiences at all the places I've worked. That is: raw requirements cause waste. A term I've used (and have heard others use) is that requirements are either "baked" or "not baked". For a development team to plan an iteration, or a scope of delivery, the requirements need to be baked. If we pull the development team into a planning session, we ensure the requirements are fully baked before the meeting. Developers will be asking specific questions about the details of the requirements, and answers need to be readily available.
A big cause of waste is when a project manager inaccurately declares the requirements as actionable and the entire team meets. This is the most expensive meeting you can have. As soon as the developers ask questions, a discussion ensues among business stakeholders on what the requirements should be. At this point, the developers sit and listen until the stakeholders finish defining what the system should do.
The above is a strong indicator that the requirements aren't baked. There are holes in the analysis, and it comes out as soon as a developer asks a question about the expected behavior.
TIP: Project Managers: ensure the requirements are fully baked BEFORE you take up the ENTIRE team's time. You may need help from the architect or tester, but ensure the center is not raw when the whole team is pulled in.
UPDATE: ScottBellware was a bit confused about the context of this post (see comment below), so I thought others might be also. This post is about behavioral requirements for a single user story. Very small scope. Before the team can estimate, this story must be "baked". Otherwise, the coding is guesswork.