How we’ve destroyed user stories

Psst! Hey…You know there’s a simple way to get engineers to build what you want, and as a bonus you can call it “agile”…Shh! Try to keep this technique quiet. You see it’s all about user stories. All you have to do is write something like this:

The format is simple:

As a user, I want <insert functional requirement> so that <insert functional requirement again>.

Breaking this down:

• “As a user”: forget about going into details about what kind of user persona this story is for— you just want to tell engineers that a human is using the software (they often forget!)
• “I want”: this is where you write exactly what you want built. Keep it as prescriptive as possible and make sure to articulate the solution and not what the user is trying to achieve. You don’t want people to have to think for themselves.
• “So that”: you can often leave this section out (it’s not that important). But you know… people NEVER get things the first time, so sometimes you may want to repeat the same thing again. If you’re smart about it just change a few words here and there — they won’t notice.

Right?… WRONG!

Somewhere along the journey of our teams transitioning to agile practices we picked up user stories. We got incredibly excited — no longer do we have to write long functional requirements documents, but instead, using short sentence format, we could express what our customers intended to do… requirements without the long documents… or at least that was the pitch you heard.

How we got here

User stories were coined many years ago when Kent Beck defined eXtreeme programming (XP). The goal was far less about the actual format and more about the intent — to tell a story. A story of our customers, articulating the who, what and the why.

Mike Cohn then picked that up and wrote what is now seems to be the most common book on writing user stories. The book outlines how to go about identifying and writing stories.

Somewhere along the way we, the product management discipline, destroyed user stories.

We got fixated on the format without understanding the intent. We fell back to writing a list of functional, solution-oriented requirements. And because we stuck a “as a user” at the start, a “wants to” in the middle and sometimes a “so that” at the end somehow we felt all “agile” and “user focused” about it.

As with many things in life, when you get fixated on the what and not the why you forget about the initial purpose for which something was created. Why? Because we as humans naturally lean towards this way of thinking. Following a set of instructions is far easier then having to think about underlying intent.

User stories done “right”

So instead we should be thinking about them this way:

• “As” <persona>: who are we building this for? We’re not just after a job title, we’re after the persona of the person. Alana. Our team should have a shared understanding of who Alana is. We’ve hopefully interviewed plenty of Alana’s. We understand how that person works, how they think and what they feel. We have empathy for Alana.
• “Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you’ve been missing the point.
• “So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?

We could spend forever dissecting how to write user stories (or you could just read the book).

We also could sit here and start to have a philosophical debate about user stories versus job stories. We could talk about how job stories are apparently a much more “superior” way of expressing what our customers want. But again, we’ve missed the point. I’m more than confident in our ability to eventually destroy job stories just like we did with user stories.

User stories, job stories… whatever — we are getting fixated on the format and not the intent.

We’re thinking about it the wrong way

The conversation around user stories and requirements needs to be elevated back to their core purpose.

“Stories get their name from how they should be used, not what should be written.” — Jeff Patton

As product managers our goal should be to build a shared understanding of our customers and their problems. We should be thinking of stories as just one method of building a shared understanding and not the outcome.

There are many other ways we can tell stories to our teams — writing stories in this short-hand format is just one of the many tools we should have in our toolbox. In fact, I’d argue that writing something, even if you do get the format amazingly perfect, in no way means your team has the same interpretation.

Understanding our customers is a process built through conversation, not by just authoring a document. Conversation about their stories should be the beginning of a journey to building this shared understanding with our teams. Once we’ve had this conversation we can then use techniques such as user stories, customer interviews, data analysis, user story mapping, role play… heck, even job stories and many other qualitative and quantitative methods to support us in the quest to understand our customers.

We need to stop getting hung up on the format and focus on the intent.