The Most Common User Story Mistake
That Might Be True For Other Lightweight Agile Techniques, Too
In software development and product management, a user story is a description consisting of one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. […] It captures the ‘who’, ‘what’ and ‘why’ of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. — Wikipedia
When I started working with user stories, I had a lot of questions. Which format should I choose? How do I know if it’s correct? Are there any guidelines? Hey, wait, what’s a persona? The tutorial I saw last week said it’s a role… (Don’t worry. A month later it turned out I shouldn’t have worried anyway because apparently, an actor became the trendiest term.)
I’ve watched other people struggle with user stories, too. A Google search for “5 most common user story mistakes” returns 14,500,000 results. Seems that user stories — meant to be a lightweight tool — are often too lightweight for many agile practitioners who feel as lost as I did.
To ease their pain, I’m going to focus on what I consider the most common mistake. Here it is:
How you write user stories isn’t important, because a single story doesn’t matter. What matters is how your organization works with stories.
“But well-written stories make well-executed features…”
No. Teams with processes make great features.
In 2001, Ron Jeffries of the Extreme Programming fame wrote that “user stories have three critical aspects. We can call these Card, Conversation, and Confirmation.” He considers the textual artefact — the Card — nothing more than a piece of text to put in Trello or hang on the wall as a sticky note. The Card only captures a glimpse of the requirement behind the user story. It doesn’t matter how refined it is; we still need to discuss acceptance criteria, tests, success and failure scenarios, as well as define confirmation metrics to produce a well-designed feature. In short, we still need to take care of the employee engagement story’s Conversation and Confirmation.
It’s tempting to focus solely on the Card, because it’s eye candy. Words are tangible and easy to argue about. I’m not innocent, too — I remember I polished my user story cards for hours back in the day. I believed that, thanks to my work, we were going to do a better job. It felt good, but it only lulled me into a false sense of security and control.
There’s more to a user story than just its format
I don’t think anybody should believe a perfect user story guarantees a well-executed piece of functionality or that poorly-written stories can’t yield great results by definition. Nonetheless, articles about new, “better” formats still get traction: in November 2013, Alan Klement published his “Replacing The User Story With The Job Story” on Medium. “The job story”, he says in a nutshell, “is a better way to define features than the user story. It eliminates assumptions and acknowledges causality.” Maybe. But I’m not sure if this matters in the long run.
Now, please don’t take me wrong. I’m not saying the job story format isn’t good or thoughtful. In fact, I think it can be useful. But I don’t believe it improves software design on its own.
In my opinion, the process and interactions around the textual artefact — be it a user story, a job story, a use case or anything else — matter more. Not without reason, Mike Cohen’s “User Stories Applied” takes 21 chapters and 2 appendices to fully explain how a team should work with user stories to estimate, plan and manage products. (Among these 21 chapters, only one discusses writing stories.) Similarly, Gojko Adzic and David Evans dedicate 42 out of their 50 ideas in “50 Quick Ideas to Improve Your User Stories” to topics other than creating stories. Despite that, Wikipedia still characterizes a user story as “a description consisting of one or more sentences in the everyday or business language.” I think we can do better.
If we look at the job story, it was created as a story format inside Intercom as a practical implementation of the Jobs-to-be-Done concept in software product management. The Jobs-to-be-Done framework — first described in “Marketing Malpractice: The Cause and the Cure” by Clayton M. Christensen, Scott Cook and Taddy Hall — developed an idea that customers “hire” products to do some jobs for them. A product team should stop thinking in terms of customer segmentation, and find out what that job is. After all, nobody buys a drill because they’re a 32-year-old white male. People simply need a hole in the wall.
To implement Jobs-to-be-Done, Intercom not only figured out the job story format, they also adjusted their product management, design and development processes to support the concept. If they didn’t adjust, they wouldn’t have been as successful. But I bet that if they didn’t use job stories but still maintained the job mindset, they’d be just fine. For the format to work, the job philosophy has to power the end-to-end product design process, and Intercom knows that.
Invest in people, not tools
Lightweight tools like user stories are often vague frameworks; they require a lot of experience and mastery to be applied efficiently. They’re also prone to misuse, because, while they’ve got few explicit rules, they need many implicit rules to work. If you realize that, you’ll understand why it’s extremely easy to began working with user stories, but it’s difficult to use them well from the start.
People who use lightweight tools have to discover the implicit rules on their own through practice and education. Chris Matts recently wrote that agile tools don’t fix problems, they reveal them. I believe he’s right, but I also think you need immense self-awarness to own the problem instead of sweeping it under the rug and moving on. Only great teams can do that.
In his fantastic talk “Beyond Features,” Dan North explains how important continuous improvement of the team is, and how neglecting it makes the organization unbalanced. He also remarks that while 2001 Agile Manifesto encouraged valuing “individuals and interactions over processes and tools,” 2015 agile environment seems to care more about the latter than the former. Too often, he says, we shelter ourselves with frameworks meant to improve predictability and create a false sense of security. Fixating on the tools should never matter more than discipline, skills, culture — your company’s muscle memory. By saying you need a great process to succeed, I mean that muscle memory. You should constantly strive to improve it.
Agile techniques don’t optimize for mediocrity. As Pixar’s Ed Catmull admits in his fantastic book Creativity Inc. “if you give a good idea to a mediocre team, they will screw it up; if you give a mediocre idea to a great team, they will either fix it or throw it away and come up with something that works.”
Catmull’s honesty sounds excruciatingly eye-opening. I think we must always be aware of what he and North said if we want to avoid thinking we’re doing well when in fact we’re not. I once attended an agile meet-up that didn’t discuss user stories, but raised a subject that’s connected to software requirements: specifications. “We all know,” the speaker began, “how perfectly it is with specifications in agile teams…” and then everybody laughed knowingly. To this day, I’m not entirely sure if they realized their laugh sounded helpless. Their inability to own the problem was terrifying.
My advice: to fix your user stories or — well — anything else, don’t fall for eye candy but strive to be a great team instead.
My name is Kamil Nicieja. I’m a product manager who has built software products both for my own startups and clients from the United States, Australia, the United Kingdom, Canada, Germany, and Kenya.
If you want to talk about agile techniques in your organization, just tweet or email me. I’m currently working on a book about writing Gherkin-based specifications Specification by Example-style. It’d be great to connect if you want to share your experience.
