We've been working with Scrum for a while now, generally successfully. However of late, as the pressure has started to mount up we've encountered several situations where items came through planning meetings but when it actually came time to code, it became apparent they were woefully under-specified.
This is an annoying and awkward waste of time. So I'm wondering, is there anything we can do to make sure that a work item is properly understood and planned before it's included in a sprint?
We don't use TDD, but my experiences with it suggest that it's a good way of ensuring a programmer understands a task before beginning work. So I did consider trying to work out some automated testing as a possible approach to this. But not all work items are amenable to automated tests, and it's likely to be difficult/boring for non-programmers in the meeting.
As an aside, out of curiosity, is when one has decided on acceptance criteria, should they go on a work item, or a user story, or both?