Story + PD: Agile User Stories vs loglines

Part of a series at the intersection of Storytelling and Product Development.

I’ve written elsewhere about this curious difference between stories in Agile and stories in almost any other context. I’m kind of a movie fan, so after my day job of helping people in business and product with their stories, I’m learning about how stories get to the silver screen. My screenwriting experience so far has inspired me to look at the parallels and differences between these two worlds, and how one might inform the other. 

A user story in Agile is a very specific thing: Who What Why. It’s one or two sentences, max. It’s very streamlined.

It may not be much of a “story” to me; it sounds more like a limited, standardized logline, or a value proposition statement. But as Hemingway famously demonstrated, if one can tell a powerful story using just six words. (“For sale: baby shoes. Never worn.”) then a Hollywood-style logline or an Agile story template can deliver some punch, too. But how often does it?

The Product Owner who Authors and Grooms the User Stories is taking narratives and distilling them into loglines, with ‘acceptance criteria’ that tell the team the tasks required to fulfill the User Story are completed.  If were a scene in a movie with the user as the protagonist, ‘the acceptance criteria’ is a successful plot beat that moves the story along.

However, I see a problem when I see examples: A discipline and degree of abstraction that creates distance between designer/coder/engineer and the person in that “User Story.” 

A large part of my career has been to spend time with people (what some would call “users”) listening, gathering information and narratives about their lives, goals, activities, and needs. We brought this rich data back, interpreted, sifted, and presented findings and insights for teams to feed into their development processes. Sometimes that insight was transferred experientially, sometimes with copy and a visual in Powerpoint.

If this ‘thick’ description of a user’s situation is not “groomed” into a concise, concrete User Story statement (‘thin’ description) with criteria we can measure or agree has been met, then it’s likely to get discarded. Then what? 

Is that discarded data the sometimes the difference between emotional resonance and flatness? 

In my experience, a good question during an ethnographic interview might yield 2-4 minutes of a story, which you then can follow up for detail or to learn more. This life context, or the context for an activity, can inform how someone might hope to feel after accomplishing their goal, besides “well, that’s finished.” I’ve seen engineers grow impatient during interviews, and now it’s easier to see, why when you consider what a “story” is to them. 

Then there are Product Managers who are especially sociable and curious in their personalities, and processes, who make it a point to spend time interacting with customers, learning richly. These are the type who are really customer-centric and empathic. I know a few, and I will be asking them soon, “How does that inform their User Story ‘authoring and grooming?’” 

Since this is a critical input to Agile, it seems there should be effort to train and learn about what makes for good stories, but not just as a one-line Post-It note.

And there is training on user stories. I’m finding more and more people who are seeing a need for story in product. But I’m still curious how this working in both theory and practice.

In my own practice, it’s gratifying when I’ve taken a client to from being an impatient engineer or executive, through a immersive customer encounter (like a home visit) and watched them become more empathic and engaged in the stories they hear. That emotional aperture is opened, the curiosity is triggered, and ideas begin to flow even before we land on an insight. And when we interpret this thick description into design principles, they can can speak to product direction more authentically and authoritatively. It’s a wonderful thing.