User stories are for telling not for documenting. This distinction is important; user story isn’t a trendier word for high level requirements, it is a process to help us build better products and services by creating a genuinely shared understanding amongst everyone involved. This idea of user stories as a process was described way back at the turn of the millennium by people like Kent Beck and Ron Jeffries, as the 3 C’s: Card, Conversation, Confirmation. This is still a fresh and relevant concept years later.
Ron Jeffries summarised it eloquently back then, in this short post. Don’t worry too much about the references to iterations and planning, focus on the essential message: you write a card as a placeholder for collaborative working (the conversation); you have an ongoing conversation that can be augmented by other artefacts when needed (mockups, designs, process sketches, whatever); and you finalise your agreement about what you are going to build with a set of testable examples of how the solution will work.
Over the years since 2001, the ‘user story’ has become the ‘User Story’; an artefact in formal methods and frameworks. This is unfortunate, in many ways, and it is not untypical to see training courses that prescribe a format for how you should write them, most commonly:
As a (role) – This can be an end user or a business proxy
I want – A description of what need to be done
So that – the definition of the value
So, if you find yourself in workshops and planning sessions in front of a big screen working through pre-produced lists of User Stories (note the capital letters 🙂 on a tool like JIRA then you should immediately stop all work there and then, buy everyone a copy of Jeff Patton’s seminal book: User Story Mapping, and spend the rest of the week reading and discussing it. You’re making it much harder and less enjoyable for yourself than it should be!
If you think you might need help embedding this mindset and approach then give me a shout.