

Class Registration
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:
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?