The other night I was having a discussion with a few folks about Flatsourcing and how we work. After my brief spiel about working in an agile way with technically proficient clients we started discussing how user stories fit into the process.

One of the less technical people in the conversation wasn’t familiar with user stories, so we spent a few minutes explaining the benefit of the user story versus a full blown specification doc. My favorite moment was when I got to share what I think is the best quote about the downside of large specification documents:

“Walking on water and developing software from a specification are easy if both are frozen.”
- Edward V. Berard

Once we were all on the same page again the conversation turned to what makes a good user story. Is it better to be brief and vague or slightly less brief with more detail? Do they need to be written out on a card or can you just create a quick text doc with a bunch of stories laid out in it?

It got me thinking and after doing a little searching this weekend I found this article, Writing Good User Stories, that I thought had some great insights to help me resolve my dilemma.

User stories should ultimately be short and sweet, but they can often begin as bulky and clunky…that’s the process. In the end, they should be reflective of the vision they are meant to break down. They should help a developer who may not “get” the larger picture build the blocks upon which an application is going to be based on without needing to “get” the big picture.