Chapter 36. Three Common Misconceptions About User Stories

Marcus Raitner

User stories is one of the most widely known concepts from Agile software development. Unfortunately, it is also one of the most misunderstood. I want to address three common misconceptions I see when user stories are used.

1. User Stories Are Part of Scrum

Although many Product Backlogs seem to contain user stories, and electronic tools like Jira impose that items in Product Backlog are user stories, the Scrum Guide itself does not mention the term “user story” at all. Instead, it mentions only Product Backlog items as a generic term that is open to holding features, functions, requirements, enhancements, and fixes.

In fact, the concept of a user story originates not even from Scrum, but from Extreme Programming (XP), an Agile development model that was developed by Kent Beck, Ward Cunningham, and Ron Jeffries during the C3 project at Chrysler between 1995 and 2000.

2. User Stories Are Specifications

Particularly in organizations that have been accustomed to plan-driven work for decades, I’ve observed how this pattern is frequently applied. There are customers who have a need and developers who are supposed to deliver on that need. There used to be heavy concepts as an attempt to make both parties understand each other. Today, there are—at best—tiny user stories. What remains, however, is the harmful, customer-vendor anti-pattern.

User stories have their name for a reason. A story is something to be told and to talk about. A user story is an invitation for a conversation to take place between users and developers, and not the new name for a specification to be thrown over the wall. The findings of the conversation are certainly captured, but that documentation is not the story.

Ron Jeffries proposed three Cs as a guideline for a good user story: Card, Conversation, and Confirmation. Card refers to the origins when a story was written on an index card (nowadays, a Post-It, probably). The essential message, however, is that an index card has limited space, which necessarily results in brevity and thus incompleteness. This incompleteness is an invitation for a conversation. The common understanding achieved through the conversation can be formally recorded in the form of acceptance criteria (confirmation), which then serve as the basis for test-driven development.

3. The Product Owner Writes the User Stories

This misconception is often found in combination with the previous one. The customer-vendor anti-pattern establishes responsibilities in terms of handovers. The Product Owner, as representative of the users, “obviously” has to provide the Development Team with comprehensive specifications, which they need to implement. This continuation of the old anti-pattern is even worse, as Development Teams expect a Product Owner to do exactly that. The only change is that these comprehensive expectations are expressed nowadays as user stories, which implies that the Product Owner must write them. As the Product Owner cannot do this alone due to the abundance of stories (turning life into a “story hell”), entire specification teams are created to write perfect user stories, which are then thrown over the wall to the Development Teams.

A user story is a promise for a conversation.

Alistair Cockburn

Ultimately, it’s not about the user story as an artifact and who writes it. It is about connecting users and developers and growing a mutual understanding. Therefore, act as one product development team. Abandon the divisive customer-vendor dogma.