50% discount coupon

International Product Owner Foundation

Steen Lerche-Jensen


9.1 A User Story

A User Story is one or more sentences in the everyday or business language of the consumer or end-user of a system that captures what a user does or needs to do as part of his or her job function. User Stories are harnessed with agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. 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.

The Product Owner, based on his or her interaction with the Stakeholders, business knowledge and expertise, and inputs from the Team, develops User Stories that will form the initial Prioritized Product Backlog for the project. The Prioritized Product Backlog represents the total sum of what must be completed for the project. The objective of this exercise is to create elaborated and refined User Stories that can be approved, estimated, and committed to by the Scrum Team. At times, the Product Owner may bring a Business Analyst to assist with writing User Stories.

Although the Product Owner has the primary responsibility for writing User Stories and often carries out this exercise on his or her own, a User Story Writing Workshop can be held if desired. In real life situations, User Stories are often written by or for business users or Customers as a primary way to influence the functionality of the system being developed. User Stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.) However, primarily it is the Task of a product manager to ensure User Stories are captured.

Here are some examples of User Stories, with Story Points:


Backlog Item (User Story)

Story Point


As a Teller, I want to be able to find clients by last name, so that I can find their profile faster



As a System Admin, I want to be able to configure user settings so that I can control access.



As a System Admin, I want to be able to add new users when required, so that...



As a data entry clerk, I want the system to automatically check my spelling so that...


9.2 Creating User Story

User Stories adhere to a specific, predefined structure, and are thus a simplistic way of documenting the requirements, and desired end-user functionality. A User Story tells you three things about the requirement; Who, What, and Why. The requirements expressed in User Stories are short, simple, and easy-to-understand statements. The predefined, standard format results in enhanced communication among the Stakeholders and better estimations by the Team. Some User Stories may be too large to handle within a single Sprint. These large User Stories are often called Epics. Once Epics come up in the Prioritized Product Backlog to be completed in an upcoming Sprint, they should be decomposed into manageable User Stories.

The Prioritized Product Backlog is a dynamic list that is continuously updated because of reprioritization and new, updated, refined, and sometimes, deleted User Stories. These updates to the Backlog are typically the result of changing business requirements.

As the Customer representative conceives a User Story, it is written down on a note card with a name and a brief description. If the developer and the Customer representative find a User Story deficient in some way (too large, complicated, or imprecise), it is rewritten until satisfactory—often using the INVEST guidelines (see Chapter 8.5 below). Commonly, User Stories should not be considered definitive once they have been written down, since requirements tend to change throughout the development lifecycle, which agile processes handles by not carving them in stone upfront.

9.3 Format for creation of User Story

A useful format for creating a User Story is the following:
"As a <role>, I want <goal/desire> so that <benefit>".

Here is an example using the format: As a Database Administrator, I should be able to revert a selected number of database updates so that the desired version of the database is restored.

9.4 User Story Acceptance Criteria

Every User Story has associated Acceptance Criteria. User Stories are subjective, so the Acceptance Criteria provide the objectivity required for the User Story to be considered as Done or Not Done during the Sprint Review. Acceptance Criteria provide clarity to the Team on what is expected of a User Story, remove ambiguity from requirements, and help in aligning expectations. The Product Owner defines and communicates the Acceptance Criteria to the Scrum Team.

In the Sprint Review Meetings, the Acceptance Criteria provide the context for the Product Owner to decide if a User Story has been completed satisfactorily. It is important and the responsibility of the Scrum Master to ensure that the Product Owner does not change the Acceptance Criteria of a committed User Story in the middle of a Sprint.

9.5 INVEST criteria for User Stories

The INVEST system features the following characteristics.






The User Story should be self-contained, in a way that there is no inherent dependency on another User Story.



User Stories, up until they are part of an iteration, can always be changed and rewritten.



A User Story must deliver value to the end user.



You must always be able to estimate the size of a User Story.


Scalable (small sized)

User Stories should not be so big as to become impossible to plan or Task or prioritize with some level of certainty.



The User Story or its related description must provide the necessary information to make test development possible.

Use the promo code: pofacademy10 and get 10% discount for the International Agile Product Owner Foundation Certification