Cons of user stories

You might think that I forgot one very important word in a title :)
No, this is what it looks like. This article is totally focused on user stories disadvantages. Don’t get me wrong. I like the idea behind user stories but I believe that this type of “requirements” can be the main reason of a huge waste — rework.

I made a research to show that I’m not the only person who is skeptical about user stories. Keep reading. This is gonna be funny.

Part 1. Pieces of articles and blog posts

All About Agile states that one of the cons to using User Stories is that they often leave out a lot of details, relying instead on their conversational method of relaying details and time of development to the customer. This can be time consuming as this documentation is not complete upfront, as it is with Use Cases, but rather relies on collaboration that may or may not be present.
source: seguetech.com

Words mean different things to different people. Even meticulously written user stories that follow a standard form leave plenty of room for interpretation.
source: jamesgolick.com

Face-to-face communication is the most effective means to reach a common understanding and to benefit from collaboration with all of the participants’ knowledge and experience. However, it can be extremely inefficient and costly when stakeholders have conflicting interests or when the need isn’t well thought out or understood. I’m not saying User Stories shouldn’t be used in this case however, just that some up front analysis work might need to be done in order for the user story to be “ready” for the team to estimate and prioritize.

Another problem with relying on face-to-face communication is sometimes it’s not possible. If your software is being outsourced, or if you’re developing a complex product where different pieces are being developed by contractors and subcontractors, it’s not very feasible to have developers communicating with the customers face-to-face every time a question arises.
source: batimes.com

In XP, user stories are meant to feed into the planning game (adapted from “The New New Product Development Game,” a frequently cited 1986 article in the Harvard Business Review by H. Takeuchi and J. Nonaka). But if a team is going to make estimates and plans based on user stories, they need to at least know what needs to be done and approximately how. This is particularly true of novel systems, where there are no established current practices to be described. That means we need to give some thought to the purpose, shape, and size of the system before writing user stories. Unfortunately, many Agile adopters believe that design is a bad thing, even though this is not actually what the Agile Manifesto and its “Twelve Principles of Agile Software” say (“big design” up front is bad, but rough design is not). So, not surprisingly, estimates and plans made with premature user stories may not be very reliable.

Even in small systems there are likely to be scores, if not hundreds, of user stories. To read and write “As a <role> I want…” each and every time is both monotonous and time-consuming. When we look at how people scan and read material, superfluous words at the beginning of sentences are particularly troublesome, since they move the more important content further into the text, thereby making it harder to process.
source: interactions.acm.org

Part 2. Pieces of discussions from Quora

User stories are not requirements.
They are planning tokens; placeholders for a future conversation.
I fully accept the concept has been ‘commercialised’ to the point where its beyond meaningless. Most of what I see written about ‘stories’ these days is pure dogma because no one is going pay £1000 a day simply to be told the the above sentence. Artificial bullshit is added that ‘creates work’ ( the worst possible form of waste ).
The ‘best’ form of requirement is an executable test. Because:

It is unambiguous. ( strict inputs and outputs )

It is repeatable. ( no bias, mistakes or misinterpretation )

It is executable ( and so easily re verified, frequently and efficiently ).

It is therefore formal. You software either passes it or it doesn’t. Requirement met, or requirement not met.
by Simon Millward on Quora.com

It requires a collaborative relationship between the business users and the development team to further elaborate the definition of the requirements as the project is in progress. A popular saying is that “a user story is a placeholder for conversation”. This, in turn, also requires some sophistication on the part of the development team to be able to work directly and communicate directly with the business users rather than simply coding something from a well-defined spec.
by Chuck Cobb on Quora.com

User stories can be tricky to write well; many people just write according to the script (As a <blank>, I want <feature/product> so that I may <problem/reason/goal>). While that’s important, it’s more important to ensure that what you’re dreaming up for your users is what they actually need. Complex and detailed analysis needs to be conducted before writing user stories, and often they need to be revised and revisited to ensure their essence is still valid.
by John Paz on Quora.com

Part 3. My thoughts on user stories

3.1 Vacation photos

What you record during conversations works like a vacation photo, it helps you and others remeber the conversation. Documents should work like vacation photos, i.e. they should help you remember your discussions.

Jeff Patton

Let’s make it clear.
Conversation is an interactive communication between two or more people.
Records that are made during the conversation are called notes.
Note is a brief record of something written down to assist the memory or for future reference.

Did you get what I’m trying to say? Interactive communication between two or more people means using words, right? I’d like to remind you that same words mean different things to different people. Especially when you speak about such a complex stuff like a software.

Can notes work like vacation photos? Depends on person who read them. Memory is not very reliable thing. What did I say just now? :)

3.2 Look at the score

Product people should take care of a lot of things. To be more specific I will show you this pretty short list:
- define the problem and value proposition
- define the market and customers
- define the requirements
- communicate with stakeholders
- go through the feedback loop again and again

Are you a product manager? So, you know how valuable is the time you have. Should you avoid conversations? No! Should you avoid empty talks? YES!

A product requirements should be like a musical score — accurate and concise. If you were learning to play a song and have forgotten a fragment, you shouldn’t have to go to its author. Just get back to the score.
Oleg Avrah

Conversation -> Notes -> Requirements.
Do not waste your time on answering the same questions again and again. Transform the conversation into precise requirements and keep an eye on development process just to make sure that your team follows the right course.

3.3 What about the support?

Any system needs support. What if some people leave your team? I mean those people who’ve read your user stories and took part in discussions and implementation. You hired new engineers. Do they have that “vacation photos”? I don’t think so.

Let’s draw the bottom line

User stories have many advantages and can be really helpful but they can be the main reason of the huge wastes. Are you using user stories? So, you need to make sure that your conversation-based process is running well or find some time to transform your user stories and notes into something more precise.