Introduction

In software engineering, misunderstandings are the root of all evil .

“Software requirements is a communication problem” is the first statement in the book “User Stories Applied” from Mike Cohn. In fact, misunderstandings are the major cause of problems in software engineering. The aim of user stories is to mitigate this problem.

Build Shared Understanding

Purpose The originally intended purpose of user stories is to build shared understanding .

The actual intend of user stories is very simple, it is so simple that this concept is often misunderstood. User stories are not about requirements specification or sprint planning. As Jeff Patton writes in his book “User Story Mapping”:

“Stories in Agile development get their name from how they should be used, not what you write down.”

And further Jeff Patton says:

“The real goal of using stories is shared understanding.”

A user story tells a journey through a system or multiple systems. Often the user reaches a goal at the end of his journey. It's important that stories are written or told in a simple language without any technical details. In its original form, user stories don't have a predefined format or length. It's even not necessary to write them down. When a user story is told, everyone - regardless of role and profession - should be able to understand how a user can reach a specific goal using the system.

Furthermore, the simplicity of user stories allows every involved person to participate in the requirements elaboration. This enhances the communication among all stakeholders, avoids misunderstandings and helps to prevent forgetting important requirements.

Represent Realization Tasks

Purpose Development processes can be organized with user stories.

In agile development processes, systems are often build one story after another. This means a user story also represents a piece of work that should be realized by developers. When implementing a user story the developers extend a system so that it is possible that the user can use the system like it is described in the story. The verification that a piece of work is done is quire easy when using stories. Someone just has to try whether it is possible to through the system like described in the story.

But as Alistair Cockburn describes, the simplicity of user stories can lead to problems when starting the technical realization. And once again a problem is intended to be solved through communication:

“When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face.”

This is a quote from a popular introduction into extreme programming - the methodology actually invented user stories.

When user stories are used as realization/backlog items, it is important to find a suitable size for them. When developer(s) must realize big stories the development progress is poorly visible and it could happen that the developers loose focus and get stuck in complexity.