I have written on user stories before, so please understand that I love user stories.  When used thoughtfully, I feel user stories can be a very powerful way to create a collaborative dynamic between the business and product developers.  User stories have the innate ability to rebalance the conversation between technical people and the business in a way that allows the business to steer development according to business customer needs, not technical implementation.

What I hate, and what I want to [DELETE], is the user story template created by Rachel Davies while working at Connextra around 2001.  IME, this awful format is the source of so MANY bad user stories, I wished the template never existed.  I think the template is so bad, I am not even going to list it on my website for fear that it might be considered an endorsement of the template.  If you want to see all the fuss, review Mike Cohn’s site for examples and a counter-argument.

There are so many reasons why I think this template is bad, but I will list my personal top three:

1. This is not the language business uses to discuss features.  I see many, many Product Owners and business analysts struggle with trying to take their complex ideas and cram them into this programmer-centric language.  I suspect many hate writing user stories, but since this is user story “best practice”, they soldier on trying to make it work for them.
2. The template encourages lazy thinking about the features, why they are valuable for the business and how to validate if the feature exists and works as intended.  As a result, I watch people sleepwalk as they document their user stories.  I see lots of generic “user” or “system” user stories or stories where the feature is duplicated in the second part of the template.  For example, “As user, I want to search for a job so that I can find a job”.  Ugh!  Just kill me if I find that story in a Product Backlog.  And don’t get me started on acceptance criteria, since there never is any, it is completely untestable or repeats the feature again.
3. It is difficult to scan a Product Backlog of user stories when there are in the form of this template since there is a lot of repetitive, empty words – “as a”, “I want”, “so that”.  If you only have about 10 to 20 stories, you can weed through the extra words and deal with it.  If you have 60 to 100 stories, like a healthy Product Backlog should, then people lose both the forest and the trees.  Also, when duplication exists in code, a higher level abstraction is normally missing.

Imagine my surprise when last week (or so), I read a tweet from Jason Yip (@jchyip) that linked to a 2010 entry by JK Werner.  The title of that entry was “So that..so what?”  This thoughtful essay explains my attitude around why I really hate this template – the conversation is completely backwards and forces the business people to engineer the solution for the product developers.  This is the fault of the template and the programmer-centric thinking that underlies the template.  This is not too surprising since the template author was a programmer and programmers want the business to tell them the solution.  They constantly ask the business, “What do you want us to build?”

In contrast, the business knows what sorts of outcomes they are trying to achieve or the value they want to provide to the customer or user.  IME, business people can (mostly) describe what sort of outcomes they are trying to achieve.  If they cannot, then writing user stories is not going to help them and they need to return to some period of elaboration.  The difficulty lies in defining the solution.  If they knew the solution, then they would not need to hire the engineers.  Unfortunately, all that people have to help them is this template and the template gets the conversation between the business and the product developers all wrong.  With Rachel’s 2001 template, the focus is on feature and then value.  However, the focus should be on value and let the engineers define the feature.

My final rant on this topic – why is it so many of my consulting and coaching peers must phrase even the most basic request in this silly format.  Just today I was reading a survey and the survey author wrote this bad user story: “As a trainer, I want to attend the retreat so that I can…”  When I read this, it was like fingernails on a chalkboard.  Why not just ask me, “Why do you want to attend the retreat?  What does a good outcome look like for you?  How would you know that you achieved that outcome?”  Not everything needs to be in the form of a user story.  I think as humans we mostly have basic human interactions down well enough.  Why use this hooky language just to ask me a simple question?