One of our clients asked us the other day when a User Story has the right quality. The question was, how do we know when the team should reject them?

User stories are everywhere in the Agile world. The first time they were used by Kent Beck as part of Extreme Programming. Since then a lot has experimented with them.

User Stories are the part of the daily life of any Scrum team. We groom them - clarify, split and/or estimate - in the Product Backlog refinement sessions. We select the user stories with more business value in the Sprint Planning. The teams work on them  - refining, writing test cases and/or implementing - during the Sprint. 

At the end of the Sprint, the stories are reviewed by the team to try to get as much feedback as possible from the stakeholders. That's a pretty good lifecycle but coming back to our original question above. How do we know when the team should reject them?

Well, we believe user stories should be refined by the whole team. When a user story is not ready, the team should not reject and push back to the Product Owner. We like it more when the team collaborates with the Product Owner to get the right Description and Acceptance Criteria. User stories, as explained by Ron Jeffries, are composed of the three Cs a Card, a Conversation and a Confirmation. It is the Conversation which happens constantly between the whole team which is the key and the solution our client was looking for.