A user story is a lightweight description, usually provisioned as a document, for quickly and effectively capturing a requirement from the perspective of an end user. Or, more precisely a digital persona. 

User stories are usually used in scenarios such as product management and software development. Under, but by no means limited to, an agile framework. But I would suggest that they should be by no means limited to just software development. In fact I’ve found them to be a great way of capturing goals across many types of project and in many industry sectors. From the capturing of requirements for the selection of a Customer Relationship Management (CRM) platform. To the implementation of analytical dashboards from the capturing of data from manufacturing machines.

So why are user stories so good in capturing requirements? Because they capture the requirement from the perspective of the user. Or more precisely, the persona. They are simple and concise. And they are fully understandable from the perspective of technical and business personas. A user story does exactly what it says on the tin.

But remember that a user story does not document a feature or a requirement, persae. A user story should document a person’s end goal. Usually no more than a one-page document, summarising:

AS A – The Who

I WANT TO – The What

SO THAT I CAN – The Why

ON – The When

User stories become effective at the start of a project at the requirements gathering stage. If applied correctly they are great at visualising requirements from the perspective of the digital persona. 

You will notice I don’t use the term end-user and opt for digital persona. This is because the term end-user, by it’s very terminology, refers to a user of the product, feature, service etc. The term user, guides the requirements gatherer (usually a Business Analyst) towards visualising the end goal, only from the perspective of the user. Whereas a digital persona can refer to anyone who comes in to contact with the feature. A lot of the time these will be the same people. But sometimes we might find a non-user who’s user story becomes a game-changing idea! So by adopting the term digital persona, we get the project started in the right frame of mind. By keeping our minds open to all opportunities.

For example, when developing a new airline booking mobile app, users would typically be travellers, company stakeholders, marketing, and administration users. All would have direct input into the requirements of the new platform. And rightly so. It’s important their requirements are captured. But what about other people with a more indirect connection to the app? For example, the pilot and the crew. It’s true, they will probably never touch the app. And so if our only scope is from the perspective of the user, then the pilot and crew personas won’t be included in our requirements gathering. And yet they might have amazing ideas. Game-changing ideas! And there is the added benefit that by the very fact they are not directly involved in the day-to-day scope of the workings around the app, then their ideas are not likely to be constrained by the boundaries of that scope. And so by adopting the terminology of the digital persona, this is where we can start to get out-of-the-box ideas. Ideas that can become differentiators from our competitors.

And so how and when do we capture user stories? I find the best time in a project to put user stories together are, as part of or just after the brainstorming workshops.