Last year, while searching for a video on YouTube—that definitely sounded more purposeful than what was probably closer to the truth, “while I was mindlessly scrolling through social media”—I came across a video by story analyst, speaker and UCLA Extension Writers’ Program instruction and author Lisa Cron called “Wired for Story”.
This quotation (at 44′ 05″) stood out for me:
A story is about how what happens affects someone in pursuit of a deceptively difficult goal and how that person changes internally as a result.Lisa Cron
It stood out for me, not just because I’m fascinated with stories and because I am in the process of a long writing project, but also because in my day job we use something called ‘user stories’.
I shared Lisa Cron’s quotation with a former colleague one day during our weekly one-to-one and we quickly started considering how this might speak to our discipline of writing user stories within software development teams.
Within various agile frameworks, “a user story is an informal, general explanation of a software feature written from the perspective of the end user or customer.” (source: Atlassian).
It got me wondering who are the characters in a user story? The customer? The developer? The whole team? The software itself?
Let’s replace ‘person’ and ‘someone’ with the word ‘character’ in Cron’s quotation.
A story is about how what happens affects [a character] in pursuit of a deceptively difficult goal and how that [character] changes internally as a result.
Agile software development is by definition customer-centric. As Atlassian says in the same article, “The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer.”
Maybe that’s the character we should be focusing on here. What if we replace ‘story’ with ‘user story’, and ‘character’ with ‘customer’?
A [user story] is about how what happens affects [the customer] in pursuit of a deceptively difficult goal and how that [customer] changes internally as a result.
That feels a little closer, but not all software changes can be classed as “deceptively difficult goals”, at least not for the customer. It certainly can be for the software development team. Should we include them in this too?
I like the idea that user stories influence a team too. Each user story is not just a story that affects the outcome of a customer’s experience of the software, but it is also part of the larger story told in the life of the software development team.
A [user story] is about how what happens affects [either the customer and/or the software development team] in pursuit of a deceptively difficult goal and how [the customer] changes internally as a result.
How the customer changes internally as a result certainly speaks to the practice of customer journey maps which can help teams visualise not only the steps that customers go through when interacting with a company or product but also their emotional journey—feelings of frustration, indifference and elation. The help identify opportunities to improve the experience.
I don’t have a neat conclusion here. I think this is going to be one of those quotations that I will reflect on a lot as experience helps to shape it further. But for now, I’m satisfied that “a [user story] is about how what happens affects [either the customer and/or the software development team] in pursuit of a deceptively difficult goal and how [the customer] changes internally as a result.” User stories change people.