Production lines are inspiring things; row upon row of machines moving in perfect synchronisation, churning out products with speed and precision. It's easy to see why it would be nice to have our software development process work the same way - fast, accurate and efficient. While there are useful lessons to be learned here, it's also important to remember the ways that building software is not like building cars, and to note the pitfalls inherent in trying to treat it as such.
Having established that the quality of our user stories is important, how can we ensure that the stories we're writing are up to scratch? It's one thing to be able to measure whether you're succeeding after the fact, but what we really want is to have some guidelines to follow so that we can avoid potential problems from the beginning. For this, it's useful to look at why they're called "user stories".
Everyone likes a good story. We all know what to look for in a story, and it's not hard to tell whether we like a story or not. When it comes to Agile development, however, it seems that a great number of developers have difficulty recognising - and writing - good quality stories. This is unfortunate, because well-written user stories are crucial in unlocking several of Agile's key benefits.