Three Common Misconceptions About User Stories

User Stories are maybe the best known concept from agile software development. Unfortunately it is also one of the most misunderstood concepts. Let’s clear up the three most common misconceptions: User Stories are not part of Scrum, they are not tiny specifications and it is not the product owner writing them.

User Stories Are Part of Scrum

Although product backlogs of Scrum Teams often contain user stories and tools like JIRA call the items in the backlog 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 for features, functions, requirements, enhancements, and fixes.

In fact, the concept of a User Story originates from Extreme Programming (XP), an agile development model that was developed by Kent BeckWard Cunningham and Ron Jeffries during the C3 project at Chrysler between 1995 and 2000.

User Stories Are Specifications

Particularly in organisations that have been accustomed to plan-driven work for decades, this pattern is frequently observed. There are customers who want something and developers who are supposed to deliver something. To make the one understand the other, there used to be heavy concepts and today there are tiny user stories. What stays is this harmful customer-vendor anti-pattern.

User stories do not have that name without reason. A story is something you tell each other and something that you talk about. A user story is an invitation to a conversation between user and developer and not a specification. The findings of this conversation are certainly captured, but this documentation is not the story.

Ron Jeffries therefore proposes the three Cs formula for good user stories: Card, Conversation and Confirmation. Card means on the one hand that a story should have a physical and tangible representation in the form of a post-it or index card. On the other hand, the limited space on such a piece of paper necessarily results in brevity and thus incompleteness. This card is only the beginning of a conversation. If a common understanding has been achieved through the conversation, this can be formally recorded in the form of acceptance criteria (confirmation), which then serve as basis for a test-driven development.

The Product Owner Writes the User Stories

This misconception is often found in combination with the previous one. The customer-vendor anti-pattern tempts to think in terms of clear responsibilities and handovers. The development team is responsible for the development and therefore expects a comprehensive specification as a user story, which “obviously” has to be provided by the product owner as representative of the users. As he cannot do this alone due to the abundance of stories, this often results in entire specification teams writing stories for the development teams.

A user story is a promise for a conversation.

Alistair Cockburn

Who writes the story is irrelevant if you see yourself as one product development team, i.e., if you have abandoned the divisive customer-vendor dogma. Ultimately, it’s not about the user story as an artifact and the question of who is responsible for it, but about users and developers understanding each other. And to that end, it helps a lot to talk to each other.

[amazon_link asins=’0321205685,1491904909,0955683645′ template=’ProductCarousel’ store=’marcrait-21′ marketplace=’DE’ link_id=’c1f0d753-f026-11e8-8ac2-732e6c077d7d’]

Leave a Reply