Planning is important. We've all heard that "failing to plan is planning to fail", and anyone who's worked in a corporate environment will have seen just how much time some businesses spend on planning for the future. For some of us, however, the difficulty is in what comes next - moving from planning to doing.
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".