On Stories

A few days ago I stumbled across the inspiring podcast Stories Connecting Dots. Markus Andrezak regularly interviews interesting people on work, agile, innovation, culture and all the rest. In an extensive dialogue with Jeff Patton, who introduced us to user story mapping, he and Jeff travel back in time to how user stories where born. This made me reflect on the way, we build our stories, and what a bureaucratic piece of reference this has become. Are user stories the new requirements specification sheet?

We use user stories to describe what the user of our application or service or product should be able to do and to describe the value that the output of the story should bring. However, my perception is that user stories have become quite complicated.

The Origins of User Stories

Jeff and Markus go back to the starting days of the agile manifesto where the first people started to think about user value. Not the technical feature description, but the user‘s value was identified to be the correct vehicle to transport the description of something to implement. But there was more. Stories where not only a list of functions and how they work, but a story about the user that needed to be told. Only by telling the story the value was to be understood by a team, making their own decisions how to bring that story to live.

"What Kent meant with stories was really stories. We should be talking with each other and telling stories about the products"

How do we write stories?

When we (in our organisation) write stories today, each story contains sections like these:

With reference to the talk of Markus and Jeff, that somehow corrupts the meaning of telling a story. It makes each single JIRA item read more like a project charter. As much as I understand the necessity to detail out certain aspects for both, product owners and developers, as much I do miss the overarching idea of what to achieve.

The risk of replacing a story to be told with a list of acceptance criteria is misunderstanding or misinterpreting the final goal - the value, that it should bring to the user.

The 3 C's

The original stories were meant to trigger the dialogue. Because in that dialogue the solution, the essence about what to build becomes clear. Ron Jeffries talks about the 3 C's: Card, Conversation, Confirmation. I have to admit, today, some of our user stories only use 2 C's: Card & Confirmation.

The conversation over a story is the essential part where the magic happens between the product owner and the development team. It creates empathy for the solution, it lets the team explore the value of the solution.

This article is a reminder to myself: Focus more on the storytelling and the emerging dialogue than on the fine-grained definition of the specification items. Ensure, that value is understood and the team is able to generate the best solution.