Questions QA/Test can ask to ensure a better user story

When teams are immature in Agile, they sometimes start working on user stories that are more like user vignettes

While Agile texts/blogs may show beautiful examples of fully elaborated user stories, it is common that, for teams struggling with Agile, user stories won't be in that form on planning day.

from @CatUserStories

 If your Product Owner is working ahead of the team and filling in the details, definition of done, and conditions of satisfaction/acceptance criteria, then that is great, but I have seen (and, at conferences, I've heard from many other teams from different companies) that one-liner user stories remain prevalent in the daily lives of Agile teams.

Ideally, the entire team will discuss the one-liner either in planning or shortly thereafter and add these conditions of satisfaction to the user story.  If this conversation doesn't happen, one or more of the following issues is certain to follow:

• The developer(s) will make assumptions about the scope and requirements for the story. It is a recipe for a wasted sprint, since the resulting code will not meet the desired expectations.
• Unit tests will be faulty because they can't be congruous with acceptance criteria if those criteria are unstated.  
• If you have QA resources, they will have to wait until later in the sprint to start work, and they'll still be working from their assumptions about the user story rather than an explicit, documented understanding of how this code should behave.

If you are in this situation, it definitely indicates a deeper problem with your Agile planning processes.  But, given that, can anything be done? 

Early in our team's Agile journey, our QA/test team independently worked to ensure these criteria were discussed and documented.  Since a QA team needs to write test cases (either for automated or manual testing), they can own raising the right questions with the development team and making sure the answers get documented in the user story.  

For each user story, QA team members would work either with the team or the individual user story owner to put flesh around the skeletal user story.  Some questions our QA team asked were:

• Are there any sorts of requirement documents, wireframes, or other sources of information you're using to develop this story? (these can be discussion points for expected behaviors)
• If this user story is successful, what specifically will be different about the behavior of the application?  What new behaviors will be available? What behaviors will no longer be available?
• What other behaviors of the system will be altered by this change?  
• Are there other system behaviors that might be broken based on the parts of the code you're touching for this change?
• Will this be English-only or localized? If English-only, will it be localized later? (a striking number of times, this question has alerted developers to consider localization in the design when it might have been overlooked before)

These are all questions a tester needs to ask to understand how to validate a user story. And based on these sorts of questions, the tester and developer can sketch out a set of acceptance criteria that can be documented on the user story and then reviewed by the product owner. 

It is definitely end-around on the process, but if your team is struggling with getting all the details in place during planing, it can have a practical benefit on your maturing team.