User Story Writing - what does that mean?

I keep hearing the question "How to write good/better user stories?". A quick search on Google reveals over 25 million hits, with the first page linking to Scrum gurus such as Mike Cohn and Roman Pichler, giving examples of "good user stories" and guidelines for writing them.

Let's dig deeper. You want to write better user stories? What does the term "user story" even mean?

"I don't think it means ..." courtesy of memegenerator.net

The Connextra template

As a <ROLE> I want <FEATURE> so that <REASON>

Some guys at Connextra figured out in 2001 that a good way of formulating user stories is with their template. It helped them solve their problem and now people make that a (near) essential part of Scrum.
An entire industry has been created helping Product Owners "write better user stories" based on this template. There are many good tips around, including clarity of reason, specific acceptance criteria, separation of concerns and many others. All of them miss the point. The Connextra template is an "agile template for writing requirements". Using that template will not result in a "User Story".

So, what's a user story?

As heretical as this may sound: can you imagine a user telling a story to the developers?
Someone has a problem or a need and talks about it. We decide to create software to solve this problem.

What's the PO's role in that?

The PO has the main responsibility of deciding which item in the backlog is the most valuable and therefore, should be delivered first. For this, it's a good idea to understand what the user's problem is, how big it is - and how much value the user gets from having it solved. This means you need to listen to the user and ask questions helping in the prioritization process. 

It's OK to act as a mouthpiece for the user in cases where users don't have a voice.

In other cases, the PO has the responsibility of ensuring that developers get first-hand information and a thorough understanding of the problem.

What's the team's role in that?

In Japan, there is a philosophy that it's the student's responsibility to understand their teacher. In western circles, students blame their teacher when they can't understand their teacher. Let's just say that a blame culture helps nobody - and that users often don't understand why they have the problem they are facing.

So, the team has the responsibility of figuring out what the user means. And there is no better way of figuring that out than by interacting and discussing with the very person who is concerned.

Rather than point fingers at the PO for requesting better stories, the team should learn to understand their users. 

Asking questions is a plausible way of learning. Creating common models is another. Blaming leads nowhere.

Experiences?

When I work as Product Owner, I'm not stuffing information into computer-aided ticket systems. And I'm not "writing user stories" at all. I create doodles. Every story card I create is a doodle. And when we get around to it, the first question my team asks is: "What do you mean with this one?" 

That's where the discussion starts. It ends when we're all on the same page. 

Take-Away

If you want to write requirement specifications, please do so. Just don't call them "user stories".

If you want to work with user stories, try telling stories and asking questions.