As I think more about addressing common User Story pitfalls, what keeps coming to mind is the idea of someone taking and noting a phone call for me while I was out.
I find the greatest challenge with user stories is indeed in writing them “right”. Many Scrum teams struggle with this ‘staple diet’. Stories are not requirements on cards! (And Scrum is not waterfall on a board with daily status meetings!) As a visual aid to help form a better mindset on the best flavor and smell of user stories – expectations, writing, using, etc. – I offer the following image.
Think placeholder for a conversation…
As Mike Cohn points out in his book User Stories Applied: For Agile Software Development, user stories are not requirements, they are prompts for a conversation with the customer and/or user. A story card, then, is only a placeholder for follow-up communication, to get confirmation. Paper cards used to note these stories may be useful in this format of a “while you were out” message pad. It contains just enough abstract content as to understand WHO to talk to about WHAT, and ideally WHY (but that can be added later once the reason is communicated and understood.)
So, think “While you were out” during story writing/workshops so there is a backlog of “calls to make” (or conversations to have) in grooming stories for release and/or sprint planning.
Thoughts?
For [much] more on User Stories Applied, see the book of same name by Mike Cohn.
Grains of Rice 
Agree. There has been a lot of confusion on stories, we have tried to distiguish the Story Card vs. a User Story. A Story Card is that reminder to have a future conversation. It’s the index card on the wall (and the electronic reference of the work item if you’re also using a tool, such as Rational Team Concert). Once the Story Card is prioritized, a User Story is the elaboration of the conversation to the sufficient level detail based on the needs of the team (e.g., experience level, complexity of the appication, etc.).
Thank you Julie. I often see teams missing the 3 C’s of a User Story. A card is one part, conversation is key, and confirmation is represented in tests, hopefully automated. Teams I’ve worked with tend to expect the card to contain 100% requirements and ready (by the BA) for estimating and development … without more conversation. This needs to change in those groups if they are going to achieve their potential as an agile team.